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ie EN TRODUET TON 


Thirty five years have elapsed since ENIAC, the first of 
EXectronic digital computers was fully developed. During this 
relatively short period of time, the computer has evolved from 
a sophisticated laboratory equipment to a sine quanon tool in 
many areas of human activity, such as industry, commerce, space 
exploration and national defense. 

This computer evolution has been marked by one distinguished 
trend: ever increasing processing capability in volumes of ever 
decreasing size. Today's so-called miracle chip has a calculat- 
ing capability greater than that of the room sized ENIAC. 

Micro-miniaturization, the art of making electronic devices 
many times smaller and lighter than ever before possible or 
envisaged, originated with the missile and space research, 
where space and weight requirements made it an absolute necessity. 
[1] The first technical breakthrough came with the development 
Sache transistor. Since 1959 the number of components fabri- 
Gated on a Single chip (circuit) has doubled every year. The 
Mistery of micro-miniaturization or Integrated Electronics 
(as otherwise is called) can be considered as made up of three 
distinct periods: [2] 

* Small-Scale Integration (SSI) (1959-1965) 

During this period, the number of components per chip 
was increased from one with single transistors to approximately 
EHE "cnedsode-transistor logic (DTL) and transistor-transistor 
lose (TTL). 
1:5 
PATOS A Aa A TAS Y SE 





* Medium-Scale Integration (MSI) (1965-1969) 
During this period the number of components per chip 
was increased to several hundred, conventional TTL, Schottky 
Miinand Complementary Metal Oxide Silicon (CMOS) logic families 
fall into these categories. 
* Large-Scale Integration (LSI) (1969-Present day) 
In 1969 the capability of the semiconductor manufacturers 
passed 1000 components per chip. The increase in complexity 
integrated circuits has continued, so that in 1978 devices 
containing 65,000 components were manufactured. In fact it 
was inevitable, that at some point a computer on-a-chip was 
developed. Microprocessors, as they are now commonly known 
are widely used in industrial and commercial applications. 
Giimesevase reduction in size of electronic components in 
computer technology has been attended by: 
Increasing processing capability. 
Peamaere neduetion in hardware cost, 
Reduction in electrical power requirements, resulting 
also in reduced power supply costs. 
Increased reliability (being one of the reasons why 
micro-miniaturization was undertaken originally). 
The advantages of the LSI technology are so vastly signi- 
ficant, that it can be said that they have cleared the horizons 


to allow computer applications to "be seen" by smaller Navies, 


like the Hellenic Navy. 











The objective of this thesis is to examine possible alter- 
natives for the acquisition of computer systems, mainly in the 
area of Command Control and Communications Cc) for the 
Hellenic Navy and to offer some recommendations in this regard. 

Section II contains a consideration on potential applica- 
tion of computer systems for the Hellenic Navy. 

Section III contains a rather lengthy examination of the 
c? management in the U.S.A. Certain of the systems considered 
are definitely beyond the acquisition scope of this thesis, 
but they have intentionally been included, in order to provide 
a more complete picture of the ch environment, as it exists 
today and its future trends. 

Sections IV and V contains a similar but less extensive 
examination of the c? management in other NATO countries and 
mothe North Atlantic Alliance itself. 

Section VI covers the Systems Analysis technique, that 
should be followed in any computer system application. 

Epson VII considers the relevant costs to a computer 
System development. 

Section VIII presents the alternatives for computer system 
acquisition for the Hellenic Navy. 

Section IX makes a summary and presents certain conclusions 
m this thesis. 


Section X provides a glossary of terms and definitions 


Mean the text of this thesis. 








Finally, Appendices A through G contain technical details 
of several computer systems and test as a complementary informa- 
iene to the main text. 

This thesis is based solely on unclassified bibliography 


and it must be noted, that certain difficulties were encountered 


due to the fact that this bibliography is not readily available. 








Ele APPLICATIONS OF COMPUTER SYSTEMS 
BIBEIHETHEREENICTNAVY 

er ec. one Of the 15 sovereign nations comprising the 
Merpen Atlantic Treaty Organization (NATO). 

Furthermore, Greece will become the 10th member of the 
European Economic Community on January 1, 1981, when the 
treaty, signed in Athens on May 29, 1979, becomes active. 

The Hellenic Navy is one of the three distinct Services 
of the Hellenic Armed Forces (the others are the Hellenic 
Army and the Hellenic Air Force). To carry out its mission, 
the Hellenic Navy is equipped with surface ships (including 
guided missile fast patrol boats), modern conventional sub- 
marines, maritime patrol aircraft and naval helicopters. A 
complex of headquarters and naval bases supports the operations 
ef these units. 

The application of digital electronic computer systems in 
the Hellenic Navy can enhance the effectiveness of the function- 
mae Or this Service. 

The following are considered as potential computer system 
applications for the Hellenic Navy: 

* Data Processing 
It can be applied in support of administrative or manage- 
ment functions. The main advantage is the more timely avail- 
Mohr OL the required information. 

eme reduction in the administrative costs can be fore- 


See che order of this reduction may not be significant. 
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Economy in personnel would not be expected. 

Generally this application is a step forward but not 
of tremendous significance. 

Weapon Systems Applications 

These applications include reliable modern communica- 
tions, tactical situation compilation and display, and control 
of sensors and weapons. 

The importance of these applications cannot be over- 
emphasized. They provide the means for the effective conduct 
Of the modern naval warfare and the survival of the naval 
forces. 

The environment where these applications might be exploited 
is foreseen to have two aspects: 

- National environment 

In this environment independent operations would be 
Sorted: 
- NATO environment 


ens environment joint operations with the Allied 


Navies would be supported. 












TOME. c? DENSGENENTFAN TAE UNITED STATES OF AMERICA 


Furrent!y, c? is the most used U.S. term for force manage- 
ment and control. Literally, it means communications, command 
and control, and includes data-processing systems that reduce 
and manipulate information; navigation systems that provide 
relative and absolute positions; a considerable variety of 
sensor systems for intelligence, reconnaissance and surveillance. 
These systems are centrally within the purview of the Office of 
the Assistant Secretary of Defense for Communications, Command, 
Control and Intelligence. [3] 

E emphasizes joint planning and operations rather than 
individual service effort and when completed, around 1985, it 
is expected to provide the interoperability capabilities required 
Bor the functioning of the individual service ee systems, when 
Operating in a joint environment. 

E finds its expression in the so-called World Wide Military 
Command and Control System (WWMCCS). 

Since the WWMCCS is a rather recent development, whereby 
the individual service c^ (and for this study the USN) have 
a history of evolution of more than twenty years, the consider- 
ation of the systems will be done in a bottom-up manner, that 
Mon che individual service to the joint services. Conse- 


Aena. the life cycle concepts for defense computer resources 


programs will be examined. 











A. NAVY COMMAND AND CONTROL SYSTEMS 
1. Shipborne Tactical Systems 
a. Naval Tactical Data System (NTDS) [4] 

NTDS is the designation given to the combination 
of digital computers, displays of various types and data links 
for the on-line collection, processing, storage and presenta- 
tion of information from sensors such as radar, sonar, optical 
Ia iceratt op ship consorts via data link. NTDS is also en- 
gineered to interface with ATDS (Airborne Tactical Data System) 
and MIDS (Marine Tactical Data System). 
The primary function of NTDS as well as of ATDS and 
Mes 2S to provide for automated organization and display of 
information for command and control teams for such purposes as 
threat detection and assessment and weapon-target allocations. 

NTDS is the offspring of studies started at MIT in 
1955, while the first test service equipment underwent evalua- 
poH in 1961 on board USS MAHAN (DLG-11), USS ORISCANY (CVA-34) 
and USS KING (DLG-10), which formed the world's first NTDS 
Mask Group. 

There are four major components to the NTDS: 

* Analog to digital (A/D) converters 

Radar and sonar and other analog information is 

converted into digital form and entered directly into the digi- 


pu computer. 


Computing equipment 








Quick storage and processing of large volumes 
of information require large capacity, high-speed digital 
computers. The computer has to communicate to exchange data, 
perform necessary calculations in accordance with stored pro- 
Beams and provide a picture of the tactical situation for 
Epeprator comprehension and action. Obviously, computer pro- 
mins 15 a crucial consideration in the system. The neces- 
sary rules of engagement for threat evaluation and weapon 
asSignment, as well as the other functions, which need to be 
Berformed, must all be carefully written down beforehand. 
Because these rules are constantly changing, the programs 
must be constructed so that they can be modified without 
disrupting the operation of the system. 

Communications equipment 

Insorderto work together as adunit, all elements 
of the force, or even several forces, must be able to exchange 
information rapidly over high-speed data links. Since the 
computers themselves can communicate via these links, the 
result is a well-integrated, coordinated operation. 

* Visual displays 

Mi Sl a Ene dboveomussm cEUDPeSentec meo 
a human Operator for comprehension or decision. Visual display 
Esusswes must present the tactical picture and allow the opera- 
tor to enter new instruction or data into the system. Consoles 


ere used for detection, tracking, identification, threat 


O OO E 





evaluation and for weapons assignment and intercept control. 
In a tactical engagement console functions can be reassigned 
or switched to an alternate console. 

The current NTDS computer program is a collection 
Berner oments, Called modules, consisting of instruction, 
Esa and control information, generally pertaining to a single 
Sperational function or capability, such as tracking. The 
modules are linked together to carry out the desired functions. 
Figure III-l is a block diagram of the NTDS functions performed 
Methin the system. [4] 

Although designed to a common concept, NTDS exists 
in a number of versions varying in size and equipment complement 
according to the age of the installation and the size of the 
Wessel fitted. The overall system has also been subject to 
Pontinueus process of updating since its introduction into 
service. By 1969, for instance, three generations of display 
devices had been employed. 

The following computers have been used as basic 


computing equipment in NTDS installations: [5] 


Computer Civilian Nomenclature Remarks 
AN/USQ-17 Estimated as obsolete 
CP642/USQ-20 UNIVAC 1200 Sco di e 


CP652A/USQ-20 u " "n "n tt 
CPo42B/USQ-20 " " " " " 
AN/UYK-7 UNIVAC 1100 Employed in new NTDS 


AN/UYK-20 Du c E5165 i i i H 
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rentes description of the GPo*52B and AN/UYK=7 
computer systems is given in Appendices A and B respectively. 

NTDS uses the CMS-2 high level language for the 
production of the operational programs. 

Restructure of the NTDS [6] 

The U.S. Navy is presently restructuring the 
mo software. Two reasons are calling for this restructure: 

* In the current NTDS there is significant inter- 
dependency between modules with a large dependency on local 
Bae seores,)thus generating almost intolerable level of Inter- 
Module/Inter-Computer (IMIC) message traffic. This modular 
architecture presently requires the modules to be large func- 
tionally orientated entities, resulting in rather heavy traffic, 
that extends the pre-1960 hardware (CP642) to its limits. 

There is a continuous requirement to reduce com- 
mand decision time in order to insure readiness against evolving 
threats due to introduction of improved weapons. This require- 
ment consequently demands an improved responsiveness in data 
processing and the achievement of a greater automation of informa- 
tion processing in the Navy's command and control system. 

With the restructure, the identified system require- 
ments are divided into functional areas, which are further sub- 
divided into smaller independent modules called tasks. Each 
of the individual tasks is designed to be isolated, without 


interdependency on other tasks, communicating as necessary via 


the common data base or the executive as shown in Figure III-2. 
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This will allow the modification or the replacement of the 
individual tasks, as operational requirements change, without 
affecting other tasks. Each functional area will be supported 
by a group of tasks, that meet the specified operational require- 
ments for that function. The development of a capability to 
maintain a "single source library" of tasks written in a host 
transferable language and a support program, that will generate 
a System tape when an NTDS ship class configuration is defined, 
are key elements of the development of the universal program 
library for all NTDS ships. 

It has been estimated that a minimum of 60% of 
the program library will be transferable (common) between all 
NDS classes. The net effect of this will be to reduce procure- 
ment costs of software for the NTDS program to between 10% to 
20% of new software costs, using existing programming techniques. 
It will not be necessary for the USN to continuously go to 
Sutside vendors for total NTDS program procurement, since only 
the new capabilities need to be designed, coded, tested and 
wW ced on the universal library. 

ee Tactical Data System (DDG2-TDS+WL7 | 
This system will be installed in 23 ships of the 
DDG-2 class under a program known as the "DDG 2 Class Upgrade," 
during ship overhauls within the period 1979-1984. 
The TDS is designed to provide data display, data 
correlation and processing, lower combat system reaction time, 


preselected threat response, coordinated control of ship's 
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weapons and the participation of the DDG-2 class in force 

EEuUoHs over a real time link. The TDS will be comprised 

of the Navy standard AN/UYK-7 computer, AN/UYA-4 displays, 
conversion and input/output equipment common to many other 
ship classes. 

The TDS capability, as envisioned for the DDG-2, 
is intended to upgrade the operational effectiveness of the 
conventional CIC and the combat systems. The operational 
functions scheduled have almost the same magnitude as those 
in larger Naval Tactical Data Systems. However due to DDG-2 
TDS functions, coupled with the improved sensors and weapons 
being added during the upgrade, will provide this class of 
vessels with the capabilities required to fulfill their opera- 
Anal missions in the 1980's. 

cC. The AEGIS Command and Control System [8,9,10] 

AEGIS is a totally integrated weapon system, pri- 
marily designed to defend against anti-ship missiles and 
generally to fulfill the mission of air defense for coming 
decades. 

AEGIS is designed to provide exceptional system 
availability, fast reaction time, great firepower, immunity to 
electronic countermeasures and extended intercept range. 

The system will be capable of automatically detect- 
Ma trecking and destroying alrborne, seaborne and land- 
launched weapons of the future, launched against the defending 


Meet. 
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Uu uek reaction and high firepower of AEGIS 
stems from the digital computer-managed operations, coupled 
with a multi-function phased array radar, capable of simul- 
taneously performing search, fire control-quality tracking 
and missile midcourse command guidance functions, in the fol- 
lowing sequence and as shown in Figure III-3: [8] 

* Horizon Search 

A highly adaptive normal mode search with an 
optimized burnthrough capability employing advanced ECM tech- 
niques; an almost immediate transition from search to track, 
minimizing reaction time. 

* Track 

erat capacity capable of handling nigh mumbers 
of friendly and hostile targets at adaptive data rates, without 
mm@eerrupting search functions. 

* Midcourse guidance 
Simultaneously with search and track functions, 
the phased array radar supplies midcourse guidance commands to 
several missiles. This permits easier launches, multiple 
engagements, longer intercept ranges and higher firepower. 
Rapid cycling, multiple purpose high fire-power launchers sus- 
tain an unprecedented launching rate. 

Terminal guidance and illumination 

CW illuminators employ increased power density 


on target and rapid frequency selection for the semi-active 


terminal phase of missile flight to minimize mutual interference 
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ERE coUntep spot jamming. Limiting illuminator use to the 
short terminal phase greatly increases firepower. 

The major component of the AEGIS system are an 
electronically scanning radar, the computerized command and 
control of the system, guidance illuminator radars, missiles 
and missile launchers. These components are shown in Figure 
III-4 and are described in short below: [8] 

* Multi-function array radar AN/SPY-1 
It is capable of automatic surveillance and the 
simultaneous detection and tracking of multiple targets. 
Operating under computer control it can neutralize enemy jam- 
ming and track and transmit guidance command to the SM-2 missile. 
Targets detected by the AN/SPY-1 radar are automatically eval- 
uated as to threat and engageability. 

Guidance illumination radars 

The most threatening targets are assigned by the 
mer r-leradar to the MK 90 guidance illuminator radars. The 
illuminators transmit radar energy, which is reflected from 
airborne or surface targets, enabling AEGIS missiles to home- 
in on the radar reflections. 

* SM-2 Standard missile 
The AEGIS SM-2 modularized standard missile is a 
semi-active terminal homing weapon with mid-course command 
guidance. It can effectively attack both airborne and surface 
targets. The missile's lethality, coupled with AEGIS fast reac- 
p usnd nrigh availability provide the needed improvement in 


System effectiveness. 
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Figure III-3: Functions of the AEGIS multi-phased 
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Figure III-4: Major component of the AEGIS system. 
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* MK 26 missile launcher 

It is a fully automated and digitally controlled 
Mmeetapurpose quick reaction launcher. It can launch both anti- 
air (SM-2), anti-surface (SM-2, Harpoon) and anti-submarine 
(ASROC) missiles interchangeably. 

* MK 552 operational readiness test system 

It monitors the overall system, detecting and 
reporting malfunctions. Thus prompt repair is effected, or 
when repair must be deferred, data for operational reconfigura- 
tion to bypass the failure are provided. 

* Computerized command and control of the system 
The AEGIS is integrated and controlled through 
three multi-purpose computer groups, first the Radar Control 
(MK 10), second the Weapon Direction (MX 12) and third the 
Command and Control (MK 130). Operations in these groups are 
facilitated by a four bay AN/UYK-7 computer complex, AN/UYK-4 
displays and associated peripheral equipment. 

The component interrelationships and functional 
loops of the system are illustrated in Figure III-5 and ae 
described briefly as follows: [8] 

* Operational status 
It is continually determined by the Operational 
Readiness System. 

De ecrin and decision 


Targets enter the detection and decision loop 


Mene AN/SPY-1 radar, other ship's sensors or data from 
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Other vessels and aircraft. Depending on the operating mode, 
targets are evaluated and when threat criteria are met, assigned 
to weapon control for engagement. In the automatic special mode, 
targets meeting governing doctrine, barring over-ride, are auto- 
tically fired upon. 
HOn Control 
In automatic, semi-automatic and casualty modes, 
weapon control inserts targets into the engagement queue and 
schedules equipment for launching and terminal illumination. 
Trial intercepts are computed and a time to fire is predicted. 
Pesitive aetion is required for firing. After missile launch, 
midcourse commands are generated using AN/SPY-1 missile and 
target position data. Weapon control reports kill results 
meek to the detection and decision loop. AEGIS offers four 
operating mode options: automatic, special, semi-automatic 
Emu Casualty. 
Manufacturers 
Mero rimercontreactor fOr tie System 15 RCA Govern- 
ment and Commercial Systems, Moorestown. 
zu ichs 
Sonedcateousiips for ins tabationme. the AEGIS 
system are: 
O Ai rerai Carriers (CV) 
PoU S WONG BEACH (CCN-9) as part of her 


medernization. 
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Soo) snips of USS VIRCINIA Class (CCN RS) 

(4) Nuclear-powered Cruiser Class (CGN-42) 

(5) Destroyers of the DD 963 Class 

(6) The new Destroyer Class (DDG-47), the leading 
ship of which is planned to meet the fleet in 
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Figure III-5: Component interrelationships and 
functional loops of AEGIS system. 


d. Shipboard Intermediate Range Combat System (SIRCS) 
pus] 


SIRCS is a major defense program begun in 1975, 
in order to develop a total combat system, that will provide 
a detection-through-engagement capacity and that will be modu- 
larly adaptable to various vessels according to individual size; 


mission and capability constraints in the post-1985 time frame. 


Mere ©€il=-6 portrays the multimission, multi-platform character- 


Bes Of SIRCS. 











SIRCS may be the primary combat system in lighter 
displacement and support vessels and will complement the longer 
range AAW and surface strike systems, such as AEGIS and Harpoon 
meme jOr combatants. It will be fully responsive to the future 
anti-ship missile defense (ASMD) and surface warfare require- 
ments of the Navy. System performance goals require a substan- 
tially greater overall capability, that presently exists in the 
areas of system reaction time, firepower, spatial coverage and 
Simultaneous engagement capability. 

SIRCS is one of the first programs planned for acqui- 
sition in accordance with the recently promulgated Office of 
Management and Budget policy on major acquisition systems (OMB 
Circular A-109). This approach is unique for a major weapon 
system in that the development plan calls for early competitive 
involvement on the part of the industry in the concept formula- 
tion and definition of the system, the operational requirement 
maentified by the nature of the threat, and the desired 
performance, reliability and cost goals for the system. This 
concise statement of requirement was tailor-made to communicate 
a very broad, but bounded, problem, to which industry could 
respond with independently conceived concepts. Three major 
Industry teams»» McDonnell Douglas, Raytheon and RCA have been 
selected to develop independent conceptual designs for a total 


system, based on their own analysis of the requirements and 


available or emerging technology. 








It was planned to select the two most promising 
of the three system concepts for competitive validation, com- 
EEenesrng in late 1977. Long range plans call for initiating 
full-scale development with the single optimum system, begin- 


ning 1980. Fleet introduction is envisioned in mid-to-late 


mas0's. 
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tactica Alrborne Systems 
a. Airborne Tactical Data System (ATDS) [4] 

Ai consists the E-2C aircraft the latest ver- 
HON ot an aircraft to be designed initially for the airborne 
picket mission, a qualified crew and an extensive integrated 
system of various electronic equipment. 

luem IDs electronic system 1s divided into four 
primary subsystems as illustrated in Figure III-7 and as des- 
eribed briefly below: 

* Detection subsystem 

Consists of the various radar raw video inputs 

ee ei lected energy and a computer detector unit. The computer 
detector determines when an actual target is detected, computes 
its location and prepares or stores the data for the data pro- 
cessing and display subsystems. 
* Communication subsystem 
It is the interface of the ATDS system with other 
EMEN s 3nd controlled aircraft. Its primary function is to 
transfer and receive binary coded data. 

* Navigation subsystem 

It is comprised of three independent but inte- 

grated navigation subsystems: an inertial set, a doppler set 
and an air data computer and compass subsystem. In addition 
to an accurate geographic reference for the TDS link the navi- 
gation subsystem enables the ATDS to establish an accurate data 


Base for its computational data. 
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Data Processing and Display subsystem 

It consists basically of a computer and three 
Euhnode ray tube display units for the crew. Its function is 

to assist in accomplishing area surveillance, threat recognition 
we valuation, control of aircraft and transfer of data to and 


meom Other TDS units. 
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Figure III-7: Airborne Tactical Data System 


The digital computer is a general purpose dual 
processor, expandable memory, solid state computer. In normal 
operation Aereo ”mputer” funeti1ons as a dual processor computer, 
With the program functions shared between the two processors. 
In the event of failure of one processor, the remaining pro- 


cessor is capable of performing all the functions with no loss 


Of tactical capability. 











The computer programs (software are modularly 
constructed and are divided into three classes: pre-operational 
mest (POT), tactical, and fault isolation program (FIP). The 
Bametion of POT is to provide pre-launch indication of computer 
status. The tactical program contains the programs required 
for operations and for monitoring of hardware. FIP is used 
HO isolate a fault discovered through POT or the tactical pro- 
gram in a particular replaceable assembly. Each of the three 
programs consists of several subprograms, which perform speci- 
wie functions. 

3. Tactical Antisubmarine Warfare Aircraft Systems 
The systems of two existing ASW aircraft are examined 
in this section, that is of the long range P-3C Orion (Shore- 
based) and of the short range S-3A Viking (normally aircraft 
carrier-based). 
BENE NEW: The P=2C Orion Data System [4] 
The basic functions of the system are: 
Classification 
A tentative classification of a newly-detected 
memoet Can be displayed by the system using stored data, includ- 
ing a pre-mission tape prepared on the ground and data coming 
via a digital data link. 
Navigation 
pana position -onobuey POosLE On zand expected 
submarine positions are continuously updated by the computer 


Bm wich the aid of inertial navigation and other data. 
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Additionally tactical maneuvers can be directed by the system, 
resulting in increased accuracy over all previous systems. 
E Tactics 

Depending on the tactical situation, the system 
is able to display alternative employment of sensors, sonobuoys 
and armament, together with a calculated probability of success 
for each tactics and keep record of the edles. as they 
are used. 
* Data Recording 
The system automatically records a running history 
of the flight on a magnetic tape. This tape can be replayed on 
the ground after landing, to assist in postflight debriefing, 
further analysis of the data gathered and briefing of succeeding 
Enews. it can also be used as a training aid for flight crews. 

Complementing the system of the aircraft and pro- 
viding support from the ground, is the Tactical Support Center 
(TSC), a computerized facility at the parent base. Using the 
Same computer as the aircraft, the TCS is able to prepare mission 
tapes for the crew, with information on possible targets and 
their specifics, as well as data from previous flights. A 
digital data link permits the TSC to receive data from an on- 
station aircraft, and to transmit new information. This link 
Meal extension of the link used by the P-3Cs to exchange data 


when relieving each other on the scene of an ASW action. 


The software modules available in the TSC system 


Ea lustpPated in Figure III-8. 
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The TSC is linked with other TSCs and the Fleet 
Commanders through the Force High Level Terminal for strategic 
eve] twmetions. 
b. The S-3A Viking Data System [4] 

It is the latest development in airborne automated 
ASW data systems and carries with it the experience of the 
ANEW systen. 

The S-3A is designed to accomplish the same ASW 
MMS sS on with acrewof four, that the'P-3C does with a crew of 
men. 

The weapon system software to support the S-3A is 
illustrated in Figure III-9. Support software is also that 
software in the TSC, which prepares a mission tape and inserts 
data for the new crew and which processes data from the post- 
enen tape. The TSC and its functions remain the same, except 
Anat the TSC is on board an aircraft carrier. Instead of the 
High Level Terminal there is an interface with the NTDS system, 
so that the complete tactical picture can be presented to the 
Task Force Commander on one unit. 

Mission software regards several categories. A 
general purpose computer is supported by a number of smaller 
Faoee2sors, physically integrated into the sensor system and 
into other systems. Some of these processors have functions 
as described below: 

The acoustic data processor software translates 


the acoustic signal received from sonobuoys to digital 
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Bate, which then are put into the system for inclusion 
tie complete tactical picture. 

The inertial navigation processor software keeps 
track of the aircraft position and from this reference point 
provides data for the location of any object or other point 
on the operators display. 

* Special processor software programs provide 
Bar setivation Of systems, which do not have their own dedi- 
ea ted computers. 

The system readiness subprograms provide the 
crew with a go/no go check on the various avionics systems 
Before starting out. 

* The diagnostic test subprograms are used, in 
case of a system failure to isolate and identify a faulty 
weapon replaceable assembly. In this way the maintenance of 
the aircraft and its system is greatly accelerated and 
Amplified. 

* The inflight training program is exploited for 
mae training of the crew, using simulated data. 

* The operational program is the tool by which the 
four-man crew manages the ASW function of the aircraft. It 
receives, records, processes, analyses, correlates and displays 
tactical data. It accomplishes this with the aid of 21 sub- 


programs shown in Figure III-10 and is controlled through the 


complete processing systems illustrated in Figure III-11. 
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Figure III-10: S-3A operational subprograns. 
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Maintenance of the systems software is the 

responsibility of the Navy. 
4. Strategic Systems 
a. Amphibious Flag Data System (AFDS) [u] 

The AFDS is a command and control system designed 
to support the Amphibious Operation, which by the very nature 
of its scope is strategic. However since the landing phase of 
the operation is tactical, the system encompasses tactıcal 
Pepasılıities also. 

The system, as it is installed in the LCC amphi- 
Dious command ship class, is the combination of an Integrated 
Operational Intelligence Center (IOIC), the Amphibious Support 
Information System (ASIS) and a Naval Tactical Data System, 
which are described briefly below: 

eee cae tea, Operations Intelligence Center (IOIC). 
It provides intelligence support for all commanders embarked 
on the amphibious ship. It communicates automatically with 
pue ASIS. 

we one btous support Information System (ASIS). 
Mines 7s the strategic component of the AFDS and it is built 
on NTDS hardware. The basic configuration is portrayed in 
Figure III-12. 

The system is an on-line, general search and 
retrieval system operating on a large data base. It provides 
users With the capability of creating, modifying and deleting 


files, as the amphibious operation progresses. The programming 
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Figure III-12: Amphibious support Information 
System (ASIS) hardware. 
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language is QUEST (acronym for Query, Update, Entry, Search, 
Timeshare). The files carried include data necessary to 
support the basic phases of the operation, such as: 

Loading data for the Force 

Landing plan 

Shore fire bombardment/air target file 

Bomb damage assessment file 

Intelligence support file 

Based on intelligence received from IOIC the ASIS 
Rousspuecs the Amphibious Plan and continues its function 
zieht through the landing phase. With the execution of the 
landing phase the files of the ASIS are revised as necessary 
by the various users in accordance with the evolution of the 
Battle ashore. 

MN Tectical Data Systems (NIDS). This is a 
configuration of the already examined NTDS, suitably tailored 
mere che command landing ship. 

Mean basically provide: 

* Air Defense capability 

WE DediPkame tte control function called Objective 
Area Flight Coordination. This module permits control and 
coordination of helicopter assault and supply operations, 
close-in support and air defense. 

The combination of the IOIC/ASIS/NTDS provides to 


all users with a capability to have access to the same up-to-date 
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En rational pieture, resulting in the elimination of errors 
and misunderstanding, which occur when plans or schedules 
change during an operation. 


be» Antisubmarine Warfare Center Command and Control 
System (ASWCCS) [+4] 


The function of ASWCCS, formerly a function of the 
ASW Force Commander ashore, has been absorbed by the Fleet 
Commander ashore (Commanders Second and Third Fleets), who is 
participating in the Worldwide Military Command and Control 
System (WWMCCS). 

With the completion of the system, the Tactical 
Support Centers (TSCs), which are, as already mentioned, 
computerized facilities at the parent ASW aircraft bases, will 
be able to exchange information rapidly through the force high 
level terminal as well as to interrogate the historical files 
of the ASWCCS, to assist in analyses of the on-going missions 


ee their results. 


ER JOTNT COMMAND AND CONTROL SYSTEMS 
l. Tactical Systems 


Ion cctiaal Information Distribution System 
zips) 1131 


omoes a high-capacity, time-division multiple 
access information distribution system providing integrated 
communications, navigation and identification capabilities. 
It is being developed to facilitate secure, flexible and jam- 


resistant information transfer in real-time among the dispersed 


ou 





and mobile units characteristic of modern armed forces. The 
most significant and unique characteristic of JTIDS is the 
system architecture, that simultaneously interconnects all 
participants. The system can be considered to constitute a 
Been co: information, which is continuously updated by each 
participant and which can be tapped to the degree desired by 
any participant. 

The basic JTIDS building block is a single commu- 
nications circuit, that simultaneously services several users. 
The capacity of the circuit is shared among the participants 
on the basis of time division, using a technique known as 
time-division multiple-access (TDMA). 

Each participant is equipped with synchronized 
clock, and is assigned a sufficient number of timeslots to 
accommodate the number of messages likely to be required by 
his mission. During his assigned transmit timeslots, each 
user broadcasts data into a commonly accessible communications 
data stream, represented by the ring in Figure III-13. All 
other elements can extract information of the type, they 
require, by continuously monitoring and sampling the data base. 
Digital processing provides each participant with selective 
access to all of the information generated by the other ele- 
ments by applying fixed and variable filters to incoming 
messages. The user does not have to request information from 


co iy, Op wait until he is notified of information 
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important to his mission; instead he decides what category of 


data he wants - such as hostile aircraft within a 50-mile 
range - and he will receive everything the system has in that 
mere JOT ya 


imme typical perticipation in the JTIDS is illustrated 
mie rioure III-12. 

The system is designed to have the highest possible 
peeviveabaljycy. If a station fails or is knocked out, the loss 
momeontined to the loss of that particular station's information 
SeweCapability, wihtout crippling the overall net capability. 

Since JTIDS operates at microwave frequencies, direct 
Gommunications are limited to line-of-sight (LOS). Coverage 
beyond LOS must be provided by relay stations. Any aircraft 
with a JTIDS terminal can be assigned the relay role and assume 
it in a few seconds. 

JTIDS has no dedicated switching centers or land- 
lines; the system consists wholly of the deployed JTIDS terminals. 
To operate within it, each tactical element need only bring a 
JTIDS into the environment. 

Approximately 20 multiple nets can be operated simul- 
taneously in the same geographical area and in the same frequency 
band, by using code division techniques. Jam resistance is 
obtained through the use of several techniques, including spread- 
spectrum modulation. 

The JTIDS relative navigation capability places each 


element in the system in a precise location with respect to 


SES 








other participants. It may not be necessary to relate this 
common grid to-map coordinates. If required, however, such 
systems as LORAN and the Global Positioning System (GPS), 
could serve as the basis for relating the JTIDS grid to map 
coordinates. 

When it enters service use, JTIDS will provide tac- 
tical commanders with powerful new capabilities, having the 
Bolllowing Significantly features: 

* A high-capacity, secure, jam protected digital 
communications primary net. 

Soo ition nets for specified tactical functions. 

SSe nee digitized voice capability. 

* A jam-protected relative navigation capability, 
Ghat enables each unit to locate itself relative to other 
Participants. 

* Enhanced interoperability among intelligence, 
command and control and mission execution elements. 

* Increased incorporation of IFF, TACAN, missile 
guidance, and RVP guidance functions; increased flexibility 
in structuring nets; and low probability, that the enemy will 
direction-find the signal source. 

* A measure of relief for crowded condition in 
the electro-magnetic spectrum. 

JTIDS will be initially implemented in the E-3A 


aircraft of the Airborne Warning and Control System (AWACS) 


and will be extended to other large aircraft, fighter aircraft, 
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tactical ships and other elements. In the case of the NTDS 
equipped platforms, Link 11 and +A communications will also 

be transmitted via JTIDS. The JTIDS development program is 
constrained to be interoperable with, and essentially trans- 
parent to, existing systems, i.e. there are no changes required 
to utilize JTIDS. There will be no operator-noticeable changes 
in link procedures; however, the hardware and system implica- 
tions have not all been assessed as yet. 

The Naval Ship Engineering Center under NAVSEASYSCOM 
momworking with NAVELEXSYSCOM, Naval Electronic Laboratory 
Center San Diego and the Joint Program Office, Hanscom AFB, 
to define the requirements for interfacing NTDS and JTIDS, and 


HR ntesrating JIIDS into shipboard combat systems. 
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4. Strategic Systems 


HE orlIdwade Military Command and Control System 
(WWMCCS) [14-17] 


SMS Nescrineion 

WWMCCS is a complex and continuously evolving 
Department of Defense (DoD) project designed to provide the 
National Command Authorities (NCA), comprised of the President 
and Secretary of Defense, with optimal capability to command 
E@ameonierol the Military Forces in a crisis or war situation. 

Conceptually, WWMCCS is a Management Information 

System (MIS), whose basic components are sensors, data storage 
and processing equipment, input and output devices, communica- 
e naks, intelligence, information, people, logistics and 
previously established plans. These components are integrated 
into a dynamic, real-time c? System, in order to effectively 
respond to the demands of the environment in which the system 
operates, so that it can influence the decision maker, when 
MÉS Lacing a crisis. 

Responsibilities within the WWMCCS ADP program have 
been assigned as follows: 

* The Joint Chiefs of Staff (JCS) have the overall 
management, centralized planning and direction of the program 
under the Secretary of Defense. 

mne WWMeCS Council provides liaison, in order to 
increase organizational coordination between the Office of 
Secretary of Defense (OSD) and the JCS with regard to WWMCCS 


matter. 
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So tn Technical Support Activity (JTSA), a 
field activity of the Defense Communication Agency (DCA), 
provides centralized technical support. 

* The Air Force, acting as the Executive Agent 
provides support of common ADP training and logistics support, 
receiving guidance from the WWMCCS managers. Figure III-14 
illustrates the described WWMCCS program organization. 

* Major Hardware/Software Overview of WWMCCS 

Starting in 1966, a plan was developed to acquire 
moet Of Standard computers and programs to support the WWMCCS. 
The selection of Honeywell Information Systems as the winning 
bidder was announced in 1971. Honeywell was to provide 35 off- 
the-shelf 6000 series computers for the various sites of the 
WWMCCS. 

Figure III-15 shows the major functional hardware 
and distinguishes between the three major hardware classifica- 
Mea oras control (FC), General Staff Support Large (GSS/L), 
pene rails tar Support Medium (GSS/M), utilized throughout the 
WWMCCS network. All systems have the capability for multi- 
programming, GSS/L and FC classes can utilize multiprocessing 
and can be classified as general purpose, medium to large scale 
processing systems capable of both scientific and business 
Prelemeced Operation. 

mecenenale:rocessom Units (CPU) 

The specific CPUs utilized in WWMCCS are HIS dels 
6080. The major characteristics of these units are summarized 


in Appendix E. 
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Remark: A medium system has only one set of processors. 





The percentage of memory dedicated to system 


software and in application programs is about 70 and 30 


respectively. 
* Communications Network Processor 
IMSS Mee tanet 359 (HESMIBN 355) Communications 
processor Ts being utilized. Major characteristics are listed 


in Appendix C. 
* Operating System (0S), Timesharing (TS) and 
Applications Software. 
- Operating System (0S) 
The General Comprehensive Operating System 
(GCOS III) is the OS developed by Honeywell for use in the 
ADO series computers. Provided with GCOS III are COBOL, 
EAn RAN and SIMSCRIPT compilers. 
- Time-Sharing (TS) 
The time-sharing system software, known as the 
Worldwide Data Management (WWDMS), was designed and developed 
by HIS specifically for WWMCCS use. It is a terminal oriented 
system, which includes the functions data base creation and 
maintenance, retrieval of information and report generation. 
Since numerous requirements cannot be anticipated during crisis 
Situations, WWMCCS has been designed to satisfy unpredictable 
as well as routine requirements, utilizing simple operation 
Eonmeands. Essentially, this means that, while normal terminal 


queries are addressed to specific files with standard output 
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See e i ime Of crisis, WWMCCS provides flexibility by 
accessing portions of multiple and outputting only the speci- 
fic data requested. 
- Applications Programs 
The applications software includes nine sub- 
systems listed below: 
1) General War Subsystem (GWS) 
2) Reconnaissance Information Subsystem (RECON) 
3) Joint Operation Planning Subsystem (JOPS) 
4) Current Situation Subsystem (CURSIT) 
5) Exercise Plans & Analysis Division Subsystem 
(E TAD) 
6) Counterinsurgency and Special Activities 
Subsystem (C € SA) 
Io? seres Planning Support Subsystem (LPS) 
me o eane & Display Subsystem (PDS) 
9) Resource Monitoring Subsystem (RMS) 
* The WWMCCS Prototype Intercomputer Network (PWIN) 
It is a three-node, experimental intercomputer 
test-bed consisting of Standard WWMCCS computers. It is used 
as a design tool for the systematic development of operating 
procedures, software and design criteria in implementation of 
the total interactive WWMCCS network. Figure III-16 shows the 
conceptual framework of the final system design. 
PWIN has numerous similarities with Advanced 


Research Project Agency (ARPA) intercomputer network. The 
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Meet Sigmiticant is packet switching, which indeirectly in- 
Greases the system security, since the packet takes different 
routes depending on line availability from source to destination. 

PWIN utilizes the Distributed Data Base (DBB) 
approach. This implies that all the information required for 
WWMCCS command and control is not located at every Command 
Memter., but is distributed within the WWMCCS community in 
accordance with operational needs and expected usage. The 
Euherent outcome Of this utilization iS increased survivability 
furing a nuclear war. 

After the operational testing of the PWIN it 
Will be expanded to connect all WWMCCS sites. 

Navy Interface with the WWMCCS 

Navy Role in WWMCCS - Naturally, the Navy parti- 
cipates extensively in the WWMCCS. The most important respon- 
sibilities include functions essential to command and control, 
Euch as: 

- Operational Direction. Involves the employment 
and coordination of combatant forces. 

- Rescurces Management.  Involves the allocation 
Be onbatant forces [or operational use. 

The Navy interface with the WWMCCS is schemati- 
cally portrayed in Figure III-17. The Navy has operational 
direction responsibilities shared between the Unified/Specified 


Commands and the Fleet Commander-in-Chief (CINC) and resources 
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management responsibilities divided between Chief of Naval 
Operations (CNO) and National Military Command System (NMCS); 
and the CNO and the Fleet CINCs. 
Additionally, the Navy has the following respon- 
Ea ties within WWMCCS asa part of its role: 
- WWMCCS support of CINCLANT and CINCPAC. 
- Operation and maintenance of Navy WWMCCS 
Command Center. 
- Telecommunications support specific 
dedicated networks. 
- Software standardization in support of the 
Navy WWMCCS program. 
- Funding support for WWMCCS as apportioned 
by On. 
- Management information system and command and 
control system support for WWMCCS requirements. 
Oca tion Structure 
Command Relationship - The WWMCCS operational chain 
of command is illustrated in Figure III-18. The following are 
Notable in this schematic: 
- The WWMCCS is extended from NCA down to and in- 
cluding the Subordinate Unified Commander/Fleet 
CINC/JTF Commander Level. 
- All the Navy service level there are both WWMCCS 


and non-WWMCCS echelons of command. 
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- The interface of the WWMCCS and non-WWMCCS 
activities occur at the Major Fleet Command Level. 
- The WWMCCS does not include the operating 
forces themselves. 
^ Operational Responsibilities 
Generally, the primary Navy operational respon- 
sibilities within WWMCCS are those which are necessary to support 
the needs of the NCA. There are six operations-related Command 
and Control functional tasks which satisfy the major operational 
direction capabilities required by the WWMCCS: 1) monitor the 
Enubsutosrtuation, to include the status of US and non-US forces, 
2) respond to warning and threat assessment, 3) employ forces 
and execute operations plans, 4) perform attack strike and 
damage assessment, 5) reconstitute and redirect forces, and 
6) terminate hostilities and active operations. 
* The Unified and Specified Commands 
The Navy is required by DoD directives to support 
CINCLANT and CINCPAC and their subordinate Unified Commander. 
This support includes Command and Control related matters. 
Service Component Commands 
The Navy's major Fleet Commanders CINCLANTFLT, 
CINCPACFLT, and CINCUSNAVEUR are involved in the WWMCCS in 
their roles as service component commanders. The command and 
Bemurol systems of their headquarters are known as Fleet 


telmend support Centers. 
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* Service Chiefs- Headquarter Commands 

The Chief of Naval Operations (CNO) supports the 
National Military Command System (NMCS) through his Command 
Center Facility. This support comes from the CNO Management 
Information System and from the Navy Command Information 
Bustem (NCCIS). 

Information System Support 

The CNO Management Information System, though 
not being considered part of the operational chain of command, 
supports the information requirements of the CNO and the OPNAV 
Staff, serves as the interface with higher echelon Information 
Systems and functions as the information system supporting the 
Navy Headquarters Subsystem of the WWMCCS. 

meN S on the other hand is an integration of 
the command and control subsystems serving the CNO, the Navy 
component Commanders and their subordinate Commanders down to 
Mé” Task Force Group level. The purpose of the NCCIS is to 
accumulate and synthesize the output from various singie- 
purpose Informations Systems, even though these systems may 
be satisfactorily meeting their own individual requirements. 
NCCIS upon completion will be comprised of the following nodes: 
1) the Navy Command Support Center (at CNO/HQ), 2) the Fleet 
Ecumand Support Centers (at CINCLANT, CINCPAC, CINCUSNAVEUR 


HQs), 4) the Tactical Fleet Command Centers (afloat). 
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Mayor Command Support Centers 
(i) Fleet Command Support Centers (FCSC) 

Ihe FCSC program integrates the Operations, 
Mmcelligence and Logistics information together with Tele- 
communications Systems in order to provide information on a 
eo] tıme basis to the Command, thereby facilitating the com- 
menda and control function. 

Bo ale es oresın fact a full time and contac 
system capable of satisfying the needs of the Fleet Commanders 
by providing them with the means to respond more efficiently 
to tasking from the NCA in response to crisis situations. 

Bepes are expected to perform the following 
mimetions: 1) all source data integration, 2) situation 
analysis, 3) resource analysis, 4) generation of plans of 
tion 9) Pesource allocation, 6) operational control, 7) 
Operational assessment, 8) report generation and dissemination. 
These functions enable the major Fleet Commanders to fulfill 
their WWMCCS responsibilities in the areas of operational 
direction and resource management. 

(1i) Navy Command Support Center (NCSC) 

The NCSC operates as an integrated command 
Sp peoet facility for the CNO. It can coordinate actions 
affecting the Navy with higher authorities in the NMCS, other 
agencies of the Federal Government, the other military services 


and intra-service matters. Since CNO does not participate in 
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the operational chain of command of the WWMCCS, the NCSC fune- 
tions only as a coordination and as an information gathering 
Macllity. 

The NCSC in fact is capable to monitor the 
entire spectrum of the Navy-related command and control 
information. In this way NCSCS provides the Navy Department 
Officials with a composite worldwide overview of Naval 


Operations. 


C. LIFE CYCLE MANAGEMENT CONCEPTS [18] 
l. Automatic Data Processing (ADP) Classifications 
Because of the diverse requirements of systems, that 
utilize computer and the complex management problems assoclated 
with acquiring and developing computer resources for these 
systems, Department of Defense (DoD) has divided computer 
systems into two basic classifications: 


a? 
4 


: Embedded Rom lens ystems (ECS) 
* Automatic Data Processing Systems (ADPS) 

An ECS is embedded within and integral to weapons, 
communications, command and control, intelligence and alr 
defense systems. 

An ADPS is a type of a computer system used to support 


administrative or management functions. 


The life cycle management concepts of ECSs and ADPSs 


are similar but differ in many important respects. 








te Cycle Concepts 

There are different directives and chains of command 
that manage the life cycle of each class of ECS and ADP systems. 
DoD Directive 5000.29 establishes policy for the management 
and control of ECSs during the development, acquisition, deploy- 
ment and support of major defense systems. A Management 
Steering Committee for Embedded Computer Resources (MSC-ECR) 
oversees the DoD ECS program and coordinates and integrates 
the ECS program into the normal defense acquisition process. 

The MCR-ECR reports directly to the Deputy Secretary of Defense. 

DoD Directive 5100.40 governs the DoD ADP program. 

This directive establishes the policy for the management and 
control of the development, acquisition, deployment and support 
of ADPSs. The Assistant Secretary of Defense (Comptroller) 
administers the DoD ADP program. 

A requirement to use computer resources, regardless of 
the class, must be documented as a result of a thorough system 
analysis. Requirements for computer resources originate in a 
number of ways. Normally the requirements for computer resources 
evolve from overall system requirements, as a result of applying 
system engineering disciplines. When computers are to be 
utilized as part of the overall solution to a system require- 
ment, specific regulations and procedures must be followed. 

ECS requirements originate in a number of ways. They 


may originate, for example, in master plans of commands or 


Seeenizations, or as a result of specific mission or functional 











analysis studies. Computer resource requirements may also 
originate as a result of system development efforts, which are 
undertaken in response to a validate Statement of Need, also 
known as a Required Operational Capability (ROC). 

ADPS requirements are examined thoroughly to determine 
if a computer is the proper means to satisfy the requirement. 
Once an analysis of all alternatives/solutions has been made 
and it has been decided that an ADP solution is the best 
approach, the result of this analysis is documented in a Data 
Automation Requirement (DAR). The DAR is jointly prepared by 
the appropriate functional area and data automation personnel. 
The appropriate functional authority must sign the DAR. 

Regardless of how the computer resources are documented 
1.e., ROC or DAR, a Program Management Directive (PMD) or 
Data Project Directive (DPD) will be used to provide manage- 
ment direction for satisfying the approved requirement. A 
PMD authorizes the use of embedded computer resources in major 
defense systems. A DPD authorizes the use of ADP computer 
resources. Once authority is given to use a computer to 
satisfy a specific requirement, configuration management 
(CM) procedures are used to manage the acquisition and main- 
tenance of both hardware and software items through their 
life cycle. The following paragraphs discuss the life cycle 


phases of ECSs and ADPSs, respectively. 
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EOS Lite Cycle 
Ihe weapon system acquisition process provides a 
Boasts tor the lite cycle management of an ECS. The life cycle 
until 1378 consisted of five major phases with three Defense 
Systems Acquisition Review Council (DSRAC) reviews. These phases 
along with the reviews were in the following order: 
D on ept Formulation 
faye ARC I 
2) Validation 
Zep Doane TI 
3) Full Scale Development 
fay DSARC III 
4) Production 
5) Deployment 
Concept formulation is the initial planning phase. 
Technical, military and economic bases are established through 
comprehensive feasibility studies, experimental development 
and concept evaluation. The objective of this phase is refining 
proposed solution or developing alternative concepts to meet an 
Bperatıonal capability, such as software to monitor an engine 
during flight. Proposed solution are refined using feasibility 
assessments, estimates (cost and schedule, intelligence, logis- 
tics, etc.), trade-offs and other logical analysis, such as 
top-down techniques. The major document resulting from this 
phase is the Initial System Specification, which documents 


total system requirements. It documents software requirements 
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elias Melevyant design and technology constraints. Also 

B contasns superficial definition of essential interfaces 
between all computer and communications equipment and personnel. 
This document is normally referred to in the Decision Coordi- 
nating Paper (DCP). 

During the DSARC I review phase the DCP is reviewed 
for completeness and relevance to DoD needs. With assistance 
from the Management Steering Committee on Embedded Computer 
Resources (MSCECR) and the Cost Analysis Improvement Group 
(CAIG), DSARC approves or disapproves the DCP. Results are 
reported to the Secretary of Defense for his approval. If 
approval is granted, the validation phase is entered. 

The validation or advanced development phase is the 
period in which major system characteristics are refined through 
studies, system engineering and preliminary equipment and com- 
puter program development, test and evaluation. The objective 
is to validate the chosen alternatives and to determine 
mmether or not to proceed into the next phase. For computer 
resources, the major definitive documents resulting from this 
phase are the authenticated system specification, the prelimi- 
nary development specifications containing system functional 
requirements for computer programs and equipment and initial 
Computer Resources Integrated Support Plan (CRISP). The ini- 
tial preparation and coordination of the CRISP are accomplished 
as soon as possible to permit the program manager to accommodate 


appropriate CRISP provisions in the full-scale development 


SOnecPacts. 
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During the DSARC Il review phase, the DSARC reviews 
the DCP for completeness and accuracy. The CAIG and MSC-ECR 
groups assist in this review. Results are reported directly 
meme secretary of Defense. The DCP is updated subsequently 
and the development phase is started. 

During the full-scale development phase, the system, 
equipment, computer programs, facilities, personnel subsystems, 
training and the principal items necessary for support are 
designed, fabricated, tested and evaluated. These include a 
system which closely approximates the production item, the docu- 
mentation necessary to enter the production phase and the test 
results, which demonstrate, that the system to be produced will 
meet the stated performance requirements. 

The development specifications are finalized and 
authenticated. Authentication of any development specification 
establishes the allocated baseline. Preliminary design reviews 
(PDRs) are held for computer program items to review the pre- 
liminary design against the respective authenticated development 
De e On Formal engineering change control procedures are 
used to prepare, propose, review, approve, implement and record 
engineering change to the allocated baseline. 

Design of a computer resource item begins following 
the acceptance of a PDR for the item. This activity produces 
engineering documentation such as flow-charts, input output 
specification, and test plans. For computer programs, design 


specification includes documentation of logical flows, 
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functional sequences and relations, formats, constraints, and 
the data base specification. This documentation is reviewed 
by software engineering personnel prior to the Critical Design 
Review (CDR). The CDR assures that the recommended design 
satisfies the requirements of the development specification. 
Apeciried pobtions of the product specification, which will be 
released for coding and testing. 

Development, ee and evaluation and initial opera- 
tional test and evaluation are conducted. Testing of computer 
programs (configuration items) is performed according to the 
formal test plans initially submitted in preliminary draft form 
mem preview at CDR, and finalized prior to the start testing. 
These activities normally proceed in Such a way that testing 
of selected program function begins early during development 
and proceeds through successively detailed levels of assembly 
to the point where the complete computer program is tested. 

During the DSARC II review phase, the DSARC, with 
assistance from CAIG and MSC-ECR, reviews the updated DCP and 
menerts mesults to the Secretary of Defense for his approval. 
The DCP is updated to reflect all the decisions and changes up 
Mco nt. the lite cycle of the system. 

The production phase is the period from production 
approval until the last system item is delivered and accepted. 
The objective is to produce and deliver supportable systems 
Sone mUcanewcommands. Provisions are made in contracts and 


follow-on support arrangements to maintain the currency of the 
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equipment/computer program configuration and associated docu- 
WEN Bron in accordance with standards. Failure to consider 
these provisions may result in support complications, obsolete 
documentation and costly "modernization" programs. 
The deployment phase commences with delivery of 

the first operational unit and terminates when the system is 
removed from the operational inventory. Operational test and 
evaluation is performed on all operational configuration items 
to assess the system operational effectiveness and suitability 
in a deployed configuration. The CRISP continues to be an 
active document during this phase. It is the basic agreement 
between the using and supporting commands for managing the com- 
puter resource. After a system is in operational use, changes 
Acute programs may be necessary to remove program errors, 
improve coding or operation, adapt to changes in system require- 
ments, or incorporate knowledge gained from operational use. 
Once deployed, ECS management integrates almost inseparably 
into the system's management. 

Beer DES Life Cycle 

The life cycle of ADPS consists of five phases: 

ie Conceptual 
ee Petini tion 
3) Development 
4) Test 


5) Operation 
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The activities performed during the conceptual 
phase are: identifying the operational requirements, defining 
initial system concepts, conducting system feasibility studies, 
performing system requirements analysis, and determining the 
design requirements and gross system functions. 

The function and system requirements are determined 
by the user with data automation support. The system require- 
ments are first documented formally in a Data Automation 
Requirement (DAR). Review and approval of a DAR are conveyed 
in a Data Project Directive (DPD). After a DAR is prepared 
Suomi DeD 1s issued, a Data Project Plan (DPP) is developed to 
detail the development and testing required to insure that the 
system meets operational requirements on time. Milestones 
defined in the DPP delineate "go/no go" decision points in which 
development progress is reviewed and formal decisions made to 
continue, halt, or delay development of the system or a component 
thereof. Cost criteria are heavily weighted in the decision 
making process. 

In the definition phase the developer defines the 
system's requirements. Examples of these are: interface control, 
expanded system requirements, computer programs, manual tasks, 
equipment, system/subsystem specifications, the data require- 
ments document and the data base specification. 

Analysis, design, coding, debugging, integration 
and development testing of computer program configuration items 


are done in the development phase. All activities such as 
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reviewing system/subsystem specification, defining preliminary 
program design, conducting preliminary design reviews, defining 
ar a inetion designs, developing test plans, conducting 
critical design reviews, coding programs, testing programs, 
developing software validation and configuration reviews and 
audits are also performed in this phase. 

The activities accomplished during the test phase 
are system testing and validation testing. The completed pro- 
grams and documents are reviewed for accuracy and completeness. 
The system is run and reviewed by the customer to validate its 
responsiveness to the requirement. Validation that the system 
meets the specific objectives and requirements of the master 
plan and approval of the system for operation completes this 
phase. 

During the operational phase, system turnover re- 
quirements are updated and the system operated on a routine 
basis. Routine maintenance is performed to meet changing opera- 
tional requirements. All changes to the system configuration 
are rigidly controlled through a well defined system configura- 
ponEehansececontrol procedure. As a minimum, change control 
documentation will contain the proposed change, the specifica- 
tion, analyses of functional and technical impacts and cost 
data. The procedure requires the approval signature of an 
authorized official and retention of the documentation for 
the system's life cycle plus four years.  Periodically the 
master plan will be updated to reflect necessary changes result- 


ing from ADP system reviews. 
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D. COMPUTER STANDARDIZATION EFFORT WITHIN THE DOD 
1. Realization of the Need for Standardization 

Since the successful employment of the general purpose 
computer in defense systems, a large number of computers have 
Meeneimtroduced in the U.S. Forces. The Army and the Navy cur- 
rently use and maintain an inventory of over one hundred com- 
puter types. Practically all of these machines have a design 
personality architecture, which must be catered to through 
Specialized software and maintenance support. 

This proliferation of computers has created quite a 
number of problems such as the following: [5] 
| Small and uneconomical procurement problems, since 
ant” buy discounts could not. be exploited. 
Untenable material and logistic support posture. 
Increased scope of personnel training requirements. 
System interface and integration problems. 

Software incompatibility- 

s Proliferation of support software such as compilers 

libraries, simulators and debugging aids. 

This problem has been felt in embedded computer applica- 
tion where at least 450 general purpose programming languages 
and (incompatible) dialects are used in DoD. [19] Whenever a 
computer architecture is changed, these costly software pack- 
ages have to be redeveloped. 


Recognition of these problems prompted the individual 
Bo. well as the DoD itself to direct their efforts towards 


the standardization of hardware and software of computer systems. 








Standardization can be defined as the art of being able 
to set "standards" at the problem state with respect fo a given 
mechnology. [20] 

A Standard can be defined as a specific entity, which 
will be used in every application, where an entity of that 
general description is required. [5] 

EN ISu5tandadrdization Efforts 

The U.S. Navy has officially established since 1971 the 
AN/UYK-7 processor as the standard large shipboard computer, 
the AN/UYK-20 as the standard shipboard minicomputer and the 
CMS-2 high level language as the standard language to be employed 
im the production of operational programs for tactical data 
systems. These hardware standards, both supplied by Sperry- 
UNIVAC, had the advantage of commonality across multiple users 
in the Fleet, but they could never be acquired competitively. 
As a matter of fact, the Navy had some requests to deviate from 
BHESANZUYK-7 standard. The most significant justification given 
Was that this computer was too large and expensive ($720,000 
average cost) for the intended application. 

Economies of scale were realized as the following 
examples show: 

' Economies due to large scale production 

As of May 1976, 824 AN/UYK-20 data processing systems 


had been ordered and 637 produced. Although actual savings 
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realized are not known, the economies of large scale produc- 
tion can be seen in the volume order production for an AN/UYK- 


me ye DPS basic configuration in FY 1974. 


Quantity Seth Umeksscost ESTAN cen = 
50 $ 25,966 er 
100 walls 0.9526 
150 $ 24,324 0.9596 


* Cost savings in material support 

It has been estimated [5] that the Navy realizes 
$20,000 to $40,000 per year in Integrated Logistic Support (ILS) 
cost savings through a standardized system like UYK-20. 

* Economies due to reduction of the scope of mainte- 
nance training. 

It has been estimated [5] that the Navy saves about 
$409,000 per year in technical training costs, through the exis- 
tence of the standard UYK-20. 

* Elimination of repetitive acquisition costs of unique 
systens. 

These costs include the recurring costs for ILS, soft- 
ware maintenance and also the one-time development cost. The 
Wet 20 acquisition required $1.3 million in R&D funding for 
militarization of commercial hardware, support software, docu- 
mentation, etc. 

BUD uM Baendardızation Efforts 
The same situation has been experienced in the Army with 
the AN/GYK-12 and the AN/UYK-19 computers, although the Army 
never officially proclaimed these computers as standards. 
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3. Exploitation of the Emulation Technology 


The advent of the emulation technology, whereby the 
introduced new computer emulates the previous computer's archi- 
tecture, coupled with the DOD's desire to standardize without 
loss of competition, has led to the more recent standardication 
philosophy exhibited in the procurement of the Navy's AN/UYK-14 
computer, which uses the latest technology, as well as the pre- 
viously developed support software for the AN/UYK-20, the Army's 
competitive alternative to the AN/GYK-12 and the Air Force's 
B-1 aircraft (whose development is presently stalled in favour 
of cruise missile's development) alternative computer competition. 
As a result extensive recurring costs were saved. 

6. Joint Army and Navy Efforts [21] 

The Army and the Navy have jointly been engaged since 
1975 in a cooperative program to develop a software-compatible 
family of military computers based upon a common architecture 
and suitable for a wide range of military land, sea and air 
applications. That project is known as the "Military Computer 
memes (MCF) Project and the architecture to be used by the 
MCF is known as the "Computer Family Architecture" (CFA). 

The MCF is based upon a strategy that included the 
following: 

* Selection of erchitectural design or designers un- 
bundled from implementation or implementers. 

Standardization on architecture design as the founda- 


EB cuwhwch software investment is made. 
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Ones dera tion of commercially successful architectures 

for which software already exists as candidates for DoD adoption. 

* Technology independence, that is the anticipation of 
multiple implementations of the same architecture, implementa- 
tions, which might differ in technology (e.g., semiconductor vs. 
magnetic memory), environmental specifications (e.g., volume or 
power constraints) or reliability assurance (e.g., MIL-qualifi- 
Salon VS. Warranties or incentives). 

* Multiple sources of supply for the various processors 
and other modules of the family. 

Support (probably via emulation) of existing software 

for principal existing Army, and Navy military computers. 

The first step in the development of the MCF was the 
po meectom Of the architecture to be used. The selection was 
made by an Army/Navy CFA Selection Committee, during the period 
between October 1975 and August 1976, as a result of evaluating 
and comparing candidate architecture. The CFA committee began 
nene initial selection of nine candidate architectures, 
that is: 

~ BURROUGHS B6700 

2010573 0 

= ENTERDATA 8/32 

- GYK-12 

DECS. PDP=11 

- ROLM 1664 


SIE 32 
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- UYK-7 

- UYK-20 

The eommittee narrowed the initial set to three finalists, 
that is: 

7 7B 343709 

zEBELZPDP-11 

- INTERDATA 8/32 

Finally the committee chose the DEC PDP-11 architecture. 
Technical details of this computer are provided in Appendix F. 

The MCF has chosen to standardize at the instruction-set 
level, which presently provides the only answer to complete 
software transportability across a wide range of computer imple- 
mentations, which has stood the test of time in industry-wide 
applications. 

7. Standardization of Processing throughout the WWMCCS [16] 

The effort to standardize processing throughout the 
WWMCCS, led to the Honeywell Information System off-the-shelf 
equipment. The essential factors for the selection of Honeywell 
were the quantity buy discount and reduced selection and acquisi- 
tion costs. The General Services Administration (GSA) has stated 
that based on federal supply prices, a 70$ cost saving has been 
attained in WWMCCS hardware and software acquisition.  Further- 
more, the multiyear buy, when viewed in WWMCCS evolution, has 
Beeontiteenrly eased interfacing problems. For example, in 1971 
the WWMCCS community consisted of 31 data processing activities 


with 81 separate ADP systems. Following the Honeywell purchase 
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and a period of parallel operation, the WWMCCS configuration 
has been reduced to 46 systems, of which 35 are HIS/WWMCCS 
eomputers. 

In the same effort must be included the Navy WWMCCS 
Software Standardization (NWSS) Program, which was developed 
by NAVOSTAT to standardize ADP software, in order to satisfy 
the requirement for timely information in support of the con- 
mand and control of the Naval Forces. 

8. The Common Language Effort of the DoD [19] 

Digital computer systems costs inthe DoD for 1973 were 
estimated at $7.5 billion. About one third of this amount 
originated in each Service and a breakdown as to where this 
money was spent is as follows: 

' Computer hardware : 16 per cent or $1.20 B 


* Computer operations 
cp pone supplies : 38 per cent or $2.85 B 


: Computer software : 45 per cent or $3.375B 

Most of the software costs inthe DoD go for embedded 
computer systems as illustrated in Figure III-19. 

The programming language is the central element in the 
development and maintenance oí software. The large 
number of programming languages (at least 450) in embedded 
computer systems and the lack of any widely-used languages, 
had many ill effects such as excessive cost, slow communica- 
Bons scattered research effort, unnecessary ties to vendors, 
diversion from important tasks, diffused expenditures and risk 


in using extinct languages. 
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The common language effort is an attempt of the DoD, 
begun in 1975, to improve the quality and to reduce the cost 
of development and maintenance of software for embedded com- 
me ystems in DoD, by standardizing on a signle Higher 


Order Language (HOL). 


SCIENTIEIC 






SOFTWARE 






DROCESSING 
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EMBEDDED COMPUTER SYSTEMS 


56% 





Figure III-19: Breakdown of estimated $3 billion 
anmada EDOD SOf tware COSTS. 


Following is a rough áccount of the sequence of activity 
Minti 1 now: 

* Adoption of an interim list of approved languages 

The DoD in an effott to reduce the number of languages 

used in DoD, issued the instruction 5000.31, which specifies 
that the only approved HOLs to be used for the development of 
new defense systems software are CMS-2, SPL-1, TACPOL, J3 JOVIAL, 
J73 JOVIAL, ANSI COBOL and ANSI FORTRAN. 
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Determination of technical requirements 
The characteristics of an appropriate language were 
developed in 1975 in the form of technical requirements, acting 
as constraints on an acceptable language, without specifying 
the details of specific language features. 
' Language Evaluation 
During 1976, twenty-three programming languages were 
evaluated against the technical requirements. Included were 
languages currently being used in embedded computer applica- 
moms am the Deb (e.g., CMS-2, JOVIAL, SPL=1 and TACPOL), lang- 
uages used for process control and similar applications in 
mee pe (e.£.. EORAL-66, LIS, LTR, PEARL and RTL-2), research 
languages (e.g., EUCLID, MORAL and ECL) and languages that are 
widely used outside the DoD (e.g., COBOL, FORTRAN, PASCAL and 
aE). 
The resulting report contained the following findings: 
- None of the evaluated languages satisfied the require- 
ments in such a degree so that it could be adopted as a common 
language. 
- All the DoD approved interim languages were found 
inappropriate as a basis for developing a common language. 
- It was considered as currently possible to produce a 
single language, that would meet essentially all the requirements. 
Such a language was identified as a derivative of ALGOL-63, 


Er 027 PL/L. 
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* Competitive design of a Common Language 


Based on the previous results, the Services undertook 


a joint effort for the design of a Common Lanugage, that will 


be a derivative (but not necessarily upward compatible with) 


one of the above three languages (e.g., ALGOL-68, PASCAL, PL/1). 


Four parallel design efforts were begun on August 1977. All 


four are based on PASCAL. 


The contractors were CII-Honeywell 


bolt. Imtermetrics, Softech, and SRI International. 


The milestones for this competive design were: 


May “Sere: 
Mamen 1979: 


May 1979: 


October 1979: 


Deeisionsem. 2 desien eompetitors. 

Decision on winner of the design 
competition. 

Testing. 


Reports due. 
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IV. C? MANAGEMENT IN OTHER NATO COUNTRIES 


Following is a literature survey of Command and Control 
systems existing in or developed for the Navies of other NATO 


Beuntries. [22] 


A. CANADA 
l.  CCS-280 Command and Control System (DDH-280 Class) 


CCS-280 is an automatico data-handling and display system 
fitted on DDH-280 class antisubmarine destroyers. It is based 
on Litton L-304 single processor version digital computer Desig- 
nated AN/USQ-S501(V) Data Processing Set, it comprises one digital 
computer, eight multifunction displays and other peripherals. 
Equipment was designated to meet MIL shipborne and environmental 
Specifications. 

The computer is fitted with a 40K 32-bit word memory, 
capable of expansion to 80K words by addition of plug-in modules 
to the existing processor mainframe. Increased I/O capability 
can be achieved by adding units to the existing data bus, using 
available minor channels in the 1/0 modules. The system includes 
radar signal simulation, which provides super-imposed or separate 
Madar targets, variable in size and brightness, for training. 
Quick action buttons (QAB) in the displays provide mode selec- 
tion and independent selection of up to seven separate radar 
Videos, with independent offset and range 1-152 miles in binary 
increments. Category selection of symbology is programmable 


on-line, independently at each. 
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Basic Operating software has been provided by the 
manufacturer. The operational software was written by per- 
sonnel of the Canadian Armed Forces in a program generation 
meeility provided by the contractor. 

The operational program combines the speed and process- 
ing power of the digital computer, the comprehensive, flexible 
display and the automatic link equipment, into a system which 
provides real time coordination of sensors and weapons by the 
Command at the Unit and Force level. 

The system has the following functions: 

olle process and display tactical information 
from all systems. 

Control aircraft and other remote surface units. 
Direct own ship's and Force weapons. 

Control ship manueuvers. 

Exchange information and orders within own ship and 
Foree, 

The system is currently operational at sea in HMC Ships 
Iroquois, Athabascan, Huron and Algoquin. A shore installation 
for training and program maintenance and generation is fitted 
Buche combined support Division, Halifax. 

Manufacturers: Litton systems (Canada) Limited 


Collins Radio (Automatic Link Equipment) 


B 








B. DENMARK 
MEM UronrccPlotting (EPLO) System 

The Danish Navy has acquired an advanced version of 
the Swedish EPLO (Electronic Plotting) System.  EPLO has been 
designed to overcome the difficulties of manual techniques for 
handling the tactical situation on board small ships, such as 
fast patrol boats and corvettes. The level of sophistication 
of the system is governed by cost-effectiveness and space 
restrictions. The system compiles a tactical picture of an 
area of operations and effects data exchange with other ships 
and with naval radar control centers. 

The operational functions performed by the system are: 
* Target selection and semi-automatic tracking by means 
of track symbols on a true motion stabilized raw radar 
picture. 
Exchange of tactical data via a data link with other 
Zeiss sand shore radar stations. 
Target assignment to fire control systems of the ship 
by special assignment symbols. 
* Synthetic presentation of the plotted tactical situa- 
tion, including reference information such as maps, 
geographical grids and shore radar stations. 
Continuous recording on magnetic tape of the tactical 
situation. 
Raw radar information is presented on a horizontal 16" 


PPL, whereby synthetic data including video maps, target 
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Erscks, alısnment symbols, pointer symbols and vectors is 
presented on a 24" vertical display. 

Updating of target position is achieved in cyclic 
fashion and there are two available updating times: the slow 
cycle time of two minutes for updating 24 tracks and the fast 


erelje time of 30 seconds for updating six targets. 


Manufacturer: Stansaab Electronik AB, Jarfalla, Sweden. 
er FRANCE 
1: SENIT Naval Tactical Data Handling Systems 


The Naval Tactical systems of the French Navy are known 
under the acronym SENIT (Systeme d'Exploitation Navale des In- 
formations Tactiques) and five versions of this system have 
been identified. All of them have the broad function of gather- 
ing, coordinating and distributing sensor data and other infor- 
mation, presentation of information on appropriate displays 
Emameertain weapon control functions. A digital computer or 
computers provide the central processing facilities. The five 
systems differ in accordance with the nature and operational 
role of the vessel fitted and the sensors and armament installed. 

Following is a brief description of these systems: 

ae one YL 

Fitted on the Suffren class guided missile frigates 
Suffren (D602) and Duquesne (D603). A version of the system 
Ea "cedgeon the antiaircraft cruiser Colbert (C611). 


The system employs three IBM computers. 
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De NT 2 

This system is produced in two further versions to 
equip vessels, whose mission is Fleet air defense and radar 
Bue ket in support of the French national air defense network. 

The system is fitted on the following types of ships: 

Bourne nıps2of the Db] "Suprcouf'" elass frigates. 

that have been upgraded to carry the Tartar SAM system, that 
Meche Kersaint (D622), Bouvet (D624), Dupetit Thuars (D625), 
eA Chayla (D630). 

ree radar picket ships of the T53R class, that 
is the Le Bourdonnais (D634), Tartu (D636), Jaurequiberry (D637). 

* The experimental ship Duperre (A633) 

The SENIT 2 employs only one computer, probably a 
Hughes machine. 

EREMO SENIT 3 

Intended principally for use in ships with antisub- 
marine and antiship missions, the system provides also quick 
MeaetiOn against alr targets for self-defense. 

ieme fitted on the "Aconit" class frigates Bent 
(F703), De Grasse (F612), Tourville (F610) and Duguay-Truin 
611). The ships are armed with the Malafon antisubmarine 
mockets, MM-38 Exocet SSMs, Crotale SAMs, 100mm AA guns, L5 
antisubmarine torpedoes and can carry two WG 13 helicopters 
capable of use in antisubmarine role with MK 44 torpedoes or 


against surface targets with AS-12 missiles. 
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SENIT 3 employs 2 computers with expanded memory 
facilities. The computer equipment is provided by Hughes, in 
conjunction with a Hughes display subsystem which is produced 
under license by Thompson-CSF. 

E ENIT 4 

This version is a new system now under development, 
employing French design and manufactured hardware. 

The system is fitted on the aircraft carriers 
Clemenceau (R98) and Foch (R99) and the new C70 class frigates. 

SEN CSnploys the IRIS 55M computer in conjunction 
with ten VIZIR displays developed by Sintra. Each of these 
EM psy consoles has a potential capacity of up to 130 track 
symbols with speed vectors, an information display with 12 
memes Of 1S Characters, four circles, 23 lines of target vectors. 
The consoles are provided with tracker balls and key board data 
entry facilities. The synthetic information display has a 
character repertoire of 96 different symbols. 

ESG SENTT-S 

This version has been optimized as a basic system 
Bron whıen a range of command and control systems, that are 
compatible with varying operational requirements and weapon 
fits, can be based. The basic system is organized around the 
following equipment: 

* A CII 15M computer with 64K-bytes of store 

* Tape reader 


* Three-function radar video processor 
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One analog-digital/digital-analog converter 


oe 
s% 


A display interface (coupler) 
e o display consoles 

In this manner systems suitable for ships of 2000 
to 6000 tons can be assembled. 

SENIT 5 performs the following main operational 
RuUnctions: 

* Data acquisition from navigation, air and surface 
surveillance radars, IFF, SONAR, and EW sensors, optical sights, 
and navigation sensors. 
eco ls tua tiron compilation ineluding computer- 
aided manual tracking and/or automatic tracking of submarine, 
Surface and air targets. Creation and up-dating of EW tracks. 

Tactical situation exploitation including weapon 
system status displays, threat evaluation assistance, designa- 
tion, to weapon systems, assistance in navigation and tactical 
maneuvers. 

The display subsystem has a repertoire of 96 differ- 
ent symbols and up 70 tracks (symbol and velocity lead vectors), 
20 additional symbols, one marker and one close control symbol 
can be displayed simultaneously on all consoles. Alphanumeric 
data are also available at each console. 

The modular design permits the addition of further 
pac ties such as ASW helicopter control, automatic IFF/SIF 
code extraction, computer extension for Link 11 management, inter- 
communication with several weapon system computers, disk store 


management, recording and additional consoles. 
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Status: SENIT 5 has been produced in series since 
ENS. several countries navies have adopted it. 


HeanuUpeae turer:  Thompson-CSF 


D. GERMANY (FEDERAL REPUBLIC) 


1. AGIS (Automatisiertes Gefechts und Informationsystem 
fur Schnellboote ystem 


AGIS is a fully integrated command and fire control 
system, developed for the West German Navy new type 143 fast 
patrol boats. The principal subsystem of AGIS are radar, opti- 
cal and probably EW sensors, computer, displays, data link and 
fire control system. The weapons of this type of ship include 
four single fixed MM 38 Exocet SSMs, Seal wire-guided torpedoes 
and two Oto-Melara 76mm/62 compact dual-purpose guns. 

Display arrangements provide for 2 torpedo control con- 
soles, a gun control console, a horizontal conference-type 
Baer ical control display and a vertical tactical plot. 

The radar sensors are those of the Hollandse Signaal 
Mey intesrated fire control system, which forms a large part 
BE the AGIS installation. 

Status: The AGIS project included 10 type 143 vessels, 
fiche the first ship being operational in 1976. 

Manufacturers: 

AEG-Telefunken (Main Contractor), West Germany 


NV, Hollandse Signaalaparaten, the Netherlands 
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2. SATIR (System zur Answertung Tactischer informationen 
auf Raketenzerstoren) System 


MM zchestsetical data automation and display system 
fitted in the three Lutjens class guided missile destroyers of 
the German Bundesmarine. SATIR was developed in its stead to 
meet the German requirement and in general compliance with the 
B-2 Concept, a NATO standardized system for destroyers and above. 


Beyond theparticipation of Univac, no other reliable details are 


known. 
BEC ITALY 
1.  SADOC (Sistema Automatico Direzione delle Operazioni 


di Combattimento) Naval Processing System 


It is a completely integrated data system for the execu- 
Mon of operations and was fitted on ships of the Italian Navy 
Bmesns the period 1968 to 1973 and it is still operational. 

2. HYDRA Naval Data Automation System 

It is an advanced integrated naval combat system for 
Mse aboarda tasít naval eraft of 220 to 250 tons, armed with SSMs 
and dual guns. It is designed to coordinate the ship's opera- 
tional functions and control the weapons in a fully automated 
mode. The system provides for simultaneous engagement of multiple 
puuocsrcsoscontrotl:ing independently medium caliber guns (typically 
76mm), small caliber guns (typically 40mm) and an SSM battery 
Mes pieally OtoMat). 

It includes as subsystems the Dardo automatic digital 


weapon system, RAN-11 L/X Integrated Radar System the IPN-10 Com- 


mand and Control system and the ISN-2 integrated detection and 


jamming system. N 








Data collected are processed by computer and presented 
BE -oncerenee display, which provides a synthetic tactical 
Husplay. Computer assistance also provides for real-time threat 
evaluation, prediction, assessment of proposed maneuvers, over- 
EM Ssurp's fire control and ECM management. 


A typical arrangement is illustrated in Figure III-1l. 





Figure III-1: Elements of the Hydra systen. 


3. IPN-10/20 Tactical Data Display System 

IPN-10 system is designed for use on board small and 
medium tonnage ships, such as Corvettes, Frigates and Destroyers, 
where a simple system for the control of the tactical situation 
and of the weapons is required. 

The main tasks of the system are presentation of the 
tactical situation, by display in a clear self-explanatory 
mode and automation of some of the functions, normally performed 


EUN Scr tracking, vectoring etc.). 
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The system is comprised of the following subsystems: 
“ A number (1 to 6) of standard configuration display 


consoles, which are of a common type and are interchangeable. 


Their operational role includes surveillance, tracking, weapon 
memerOl, ASW control, tactical evaluation etc. The display 


consoles can be changed during the operation of the system, 
ena the Combat Information Genter of the ship can comply 
with the changing requirements of the tactical situation. 

* A Central Unit, which interfaces the sensors (radars, 
sonars, interceptors etc.), the weapon systems (Fire Control 
Systems, SSMx, Antisubmarine torpedoes), medium or low speed 
data links and the display consoles. 

Teemercally, the IPN-10 1s a fully digital system, 
using solid state technology. 

IPN-20 version is designed for more complex and sophis- 
Bcated data management. The system uses a larger number of 
the same consoles and the same Central Unit as the IPN Systems 
as well as the Selenia CDG 3032 digital computer. In this con- 
figuration the system is capable of handling high speed data 
memes (Such as link 11). 

Status: 

IPN-10 systems are in production and are being installed 
on the CNR 2400 fast frigates for Peruvian and Venezuelan Navies 
Eucconocthe CNR 600 tons corvettes. 

IPN-20 systems are fitted on the Italian Navy "Lupo" 


class new frigates. 
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Wenturserüren:; Selenia-indutrie Elettroniche Associate 
EAS Italy. 
A schematic of the IPN-10/20 tactical data system is 


Eustprated in Figure III-2. 
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Schematic diagram of IPN- 10/20 tactical data system 
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Figure III-2: Schematic diagram of IPN-10/20 
Tactical Data System. 


E NETHERLANDS 
l. SEWACO (Sensor, Weapon and Control System) 


The Naval Tactical systems of the Dutch Navy are known 
under the acronym SEWACO. 


A common system, that has been built within each SEWACO, 


is the DAISY (Digital Action Information System) command system. 
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This system provides direct and indirect interfaces with the 
sensors and weapons. Direct interface is accomplished by means 
of 24-bit input/output channels and indirect interface, using 
digital-to-digital, analog-to-digital and digital-to-analog 
converters. 

The display subsystem includes vertical labelled posi- 
tion displays and tabular displays, as well as a horizontal con- 
ference display. The displays offer interlaced presentations 
of both raw radar picture and synthetic information available 
From computer memory. The operator can specify the quantity 
of synthetic information to be presented on his display.  Tab- 
ular displays are used for specific Tote pages providing sup- 
plementary information, computer recommendations and answers 
Mo problems put by the operation personnel. Each display is 
Melti-functional and theoretically can perform all tasks. 

Wrewdicital computer is of the SMR-S type. 

Four SEWACO systems have been developed as follows: 

a. SEWACO-I 

Tailored for the two new guided-missile destroyers 
of the "Tromp" class: Tromp F-805) and De Ruyter (F-806), 
which were built to take the place of the two old cruisers of 
the Dutch Navy. Among the weapons associated with SEWACO I 
are the NATO Sea Sparrow point defense system and a twin 4.7" 
gun turret. Also the system provides for the inclusion of an 


Bon system. 
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b. SEWACO II 
Designed for installation on 12 new frigates of 
E c Cortenacr" class, which are presently built to replace 12 
Sa destroyers of the Dutch Navy. The 12th frigate is expected 
to be delivered in 1985. The system provides 12 operator con- 
ENS for the following functions 1) Air situation display, 2) 
Furrace situation display, 3) Electronic warfare and data link 
control, 4) Command and control, 5) Weapon direction, 6) Heli- 
copter control, 7) Antisubmarine warfare, 9) Hull-mounted 
NS lO) Ssondr signal injector, 11) Weapon control, 12) TV 
console. 
The armament associated with SEWACO II includes 8 
Harpoon SSMs, the NATO Sea Sparrow point defense system, l-76mm 
OTO Melara, MK-46 ASW homing torpedoes and 1 Helicopter (WG 13 
Nx). 
CENE CENNCO III 
Designed for installation onboard the intermediate 
age frigates of the "Van speijk" or S class (based on the design 
of the British Leander class), which are presently undergoing 
large-scale modernizations. 
Ga SEWECO IV 
This system has been designed for the new "westhinder" 
class of escorts under construction for the Belgian Navy. 
Me neons Of the sEWACO IV inelude: CU) Ar, 
surface and subsurface warning, 2) Compilation and display of 


tactical air, surface and subsurface situations, 3) Threat 


LOS 


evaluation and automatic air target selection for ensasement 
by the appropriate system, 4) Weapon assignment and fire con- 
trol by the WM 25 fire control system against air, surface, 
EX ürFoce and shore targets, 6) Electronic Warfare, 7) Data 
Be soperatzon,se) Assistance in tactical operations, includ- 
ing ASW helicopter direction and navigation, 9) Target simula- 
Bon For training purposes. 

Manufacturer: NV Hollandse Signaalaparraten, The 


Netherlands. 


ee UNITED KINGDOM 


1. ADAWS and CAATS Automatic Data Handling and Display 
Systems 


The Naval Tactical Systems of the UK Navy are known 
under the acronyms ADAWS (Action Data Automation Weapon System) 
and CAAIS (Computer Assisted Action Information System). The 
former is a full action data automation system with six versions 
being developed for various classes of ships of the UK Navy, 
whereby the latter is a cheaper and less complicated system 
intended rather for other smaller navies. 

Following is a brief description of these systems: 

a.  ADAWS 1 

Based on two Ferranti Poseidon computers, the system 
provides for the automatic compilation of the air, surface and 
Abs tace tactical situation picture using the ship's radars, 
sonars, passive direction finding equipment and data link, tar- 


get recommendation and target designation to ship's weapons. 
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ADAWS 1 has been installed since 1965 on four "County" 
class guided missiles destroyers (Antrim, Fife, Glamorgan and 
Norfolk). 

Ferranti retains a responsibility for software support. 

Manufacturers: 

Ferranti Ltd, Digital Systems Division, Berkshire, 
England all digital equipment. 

Plessey Radar Ltd, Surrey, England - display consoles. 

pe ABAWS 2 

It was the first of a new series of action data auto- 
mation systems developed for the UK Navy. It uses two Ferranti 
FM 1600 computers with a total of 128K words of core store and 
the Plessey MK 8 digital autonomous displays, to provide improved 
Facilities for the presentation of operational data in the form 
of a combined synthetic picture. 

The display system is comprised of the following units: 
* A number of labelled plan displays (LPD) used for 

Peecture Compilation and weapon control: 
* Two 3-man tactical displays used for appreciation 
of the tactical situation. 
Electronic data displays (totes), that provide alpha- 
numeric readouts of information in response to the 
operators inputs to the computer system through in- 
dividual keyboards. 


The ADAWS 2 system was designed for the type 82 guided 
missile destroyers and was installed in HMS Bristol, the only ship 


Bust was finally constructed. 
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Manufacturers: 

Ferranti Ltd, Digital Systems Division, Berkshike, 
Bnetano”- main contractor, digital equipment and software. 

Plessey Radar Ltd, Surrey, England - Displays, 
interface and drive equipment. 

cC. ADAWS 3 

This system was designed for the aircraft carrier 
mel, but was never materialized due to cancellation of the 
eo oject for that ship. 

d. ADAWS 4 

This system is essentially a version of the ADAWS 2 
and uses the same hardware, modified as necessary to accommodate 
the type 42 guided missile destroyer (GMD) class of ships. 

It is being produced in two slightly different ver- 
sions, one for the UK Navy type +2 GMDs (eight ships) and the 
type 42 class (two ships) on order for the Argentine Navy. 

The central data processing complex consists of a 
Bite tor Ferranti FM 1600 microcircuit digital computers, with 
a Plessey digital display system for the presentation of the 
e ical picture. 

The computers provide a total of 128K words core 
store and gather data from all the sensors of the ship. This 
information as well as that from other ships obtained via data 


link is assembled, correlated and presented on appropriate 


eonsoles. 








Manufacturers: 

Rerrant: Ltd, DÆ ital Systems Division Berkshike, 

England. 

Missy Radar Ltd, Surrey, England. 

e.  ADAWS 5 

This system is essentially a further version of the 
ADAWS 2 system and uses the same basic hardware and large pro- 
Ros on cof the software of that system, but configured to meet 
the requirements of the "Leander" class ASW frigates, which are 
equipped with the Ikara antisubmarine rocket. One major dif- 
ference noted is, that here only one computer is employed. 

The software is generated and maintained by a Ferranti program 
team, working at and in collaboration with the Admiralty Surface 
Weapons Establishment. 

Seven systems have been installed on seven ships of 
the Batch I Leander conversion: the HMS Leander, Ajax, Naiad, 
Galatea, Euryalus, Aurora and Arethusa. 

Manufacturers: As per ADAWS 4 

f. ADAWS 6 

This system is intended for the UK Navy new "through- 
deck cruiser" HMS Invincible. From the statements made, it can 
be Said that two Ferranti FM 1600 computers will be used and 
that the Plessey contribution will reach the 1M sterling pounds 
level. 


Manufacturers: As per ADAWS 4 
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g. CAAIS (Computer Assisted Action Information System) 

CAAIS differs from ADAWS in that it provides action 
information only, and it is designed to assist operators to 
perform their tasks with greater efficiency rather than perform 
these tasks automatically. 

The functions performed by the system are: 

automatic ins of surface and air targets. 

rem aclereompılatıon of the tactical Situation from 

radar, sonar, and electronic warfare sensor data. 

: relaying of weapon direction and target identifi- 
cation to individual weapon control systems. 
automatic communication with ships in company, 
via data link. 

The system employs one Ferranti FM 1600B computer 
Aud the Decca CA 1600 16" displays. 

An estimated total of 50 CAAIS installation have 
been ordered in various configurations for specific customers. 
Noteworthy configureations are: 

* The DBA series ordered by the UK Navy and specifically; 

- DBA 1 for general fitting or retrofitting in 
frigates. 

- DBA 2 for the type 21 "Amazon" class frigates. 

- DBA 5 for the Batch III "Leander" class frigates 
and the type 22 "Broadsword" class frigates with 


Educ omnelwsobpewestobe: 
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*^ The CAAIS 400 in the MK 10 "Niteroi" class 
frigates for the Brazilian Navy built in UK. 

Manufacturers: 

Ferranti Ltd, Digital Systems Division, Berkshire, 

Exo 


PeeccarrReadar Ltd. London, England. 
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V. c? MANAGEMENT IN NATO 


A. GENERAL 

Even though many of the NATO countries, as it has been 
acknowledged in Chapters III and IV, have successfully developed 
and implemented various automated command and control systems, 
e lance itself lacks, with one exception, a unified E 
system. 

The exception is NADGE (NATO Air Defense Ground Environment), 
the largest single defense project authorized and completed in 
NATO. This complex system, which can be considered as part of 
a future unified C^ system, involving a large number of locating 
Sites and consisting primarily of radars, computers, and elec- 
tronic data transmission facilities, provides early warning 
and response to hostile aircraft and missiles. It supplements 
and modernizes elements in nine European countries, following 
a continuous North-South sweep, that runs through Norway, Denmark, 
Germany, The Netherlands, Belgium, France, Italy, Greece, and 
Marker. [23] 

This lack of a modern unified c? System has been felt re- 
cently by the NATO Military Commanders, who have agreed that 
their most pressing need is improved command and control. [3] 
However, the problems for fulfilling the need in NATO and its 
components have their inherent difficulties. 

D en al lance of 15 distinct, sovereign nations, 


joined in a cooperative enterprise, that makes decisions by 
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committee. NATO defense programs are organized for the most 
part on a strictly national basis. The existence of national 
systems of finance places limits on the degree, to which inte- 
gration of a common programme can be effected. The difficulty 
to achieve C coordination in NATO can be appreciated consider- 
ing the difficulties of a joint capability among the four 
Services of the United States alone. 

Nevertheless, there are a number possibilities for coopera- 
tion effort towards the improvement of NATO Can which have been 
Eu edsed in NATO [23] and in USA [3] , [2*5] , e.g., through: 

Sreamdardazation (see glossary for definition) 
The use of standardized hardware and procedures, as it 
meses Deen examined in this study, solves the problems cf system 
interface and integration, and minimizes software incompatibility. 
Interoperability (see glossary for definition) 
Enforcement of interoperability allows the C? to Operate 
as a whole, with data and information exchanged throughout the 
> structure, even if different hardware and software is used. 
Cooperation in the development and production of ee 
equipment. 
eee iced particular form of standardization, which can 
exploit the benefits of scale and reduce unit costs. Cooperation 
between the European and North American parts of the Alliance has 
to be Facilitated through a "two way street" concept, as it was 


provided in the Ministerial Guidance 1975 for the Defense Policy 


epmenemoluliance. [23 | 
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The main method to achieve the above capabilities within 
NATO is through the development of relevant standards by a 
wide variety of NATO technical committees, panels, working 
groups and agencies. These bodies are generally slow moving, 
but they do provide a vehicle for the nations of the Alliance 
to be represented on important matters of common interest. 
Noteworthy is the fact that the compatibility of command 
and control systems is one of the subjects, where NIAG (NATO 
Industry Advisory Group) has offered special industrial manage- 
ment advice on procedures to be followed in international coopera- 


tion in industry with the NATO Governments. [23] 


Eee CURRENT PROCEEDINGS 

Of the many initiatives underway to improve NATO oon the 
most important are found in the recommendations of Task Force 6, 
a part of the NATO Long Term Defense Plan. These proposals 
Sever areas as listed below: [3] 

* Strategic communications systems to connect many NATO 
Beralons, oredan zations and military units. 
Data-processing systems for both NATO organizations and 
national tactical units earmarked for NATO use. 
Tactical communications systems and command-and-control 
PROCGedures:. 

Comprehensive management ofair defense, alr operations 
and air-space control functions. 


efe 
ae 


Warning, intelligence support for NATO political authori- 


ties, regional military commands and national tactical units. 
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Strategic communications is handled by NICSMA (NATO Inte- 
grated Communications Management Agency). This organization 
is responsible for architecture, system design, acquisition 
and configuration management. Participating nations contribute 
to a common fund for the acquisition and operation of the NATO 
communications systems and the agency follows a return-sharing 
formula in expending these funds. The responsibility for oper- 
ating the system is vested in a central authority under the 
Supreme Allied Commander Europe (SACEUR). 

As far as data processing systems are concerned, a different 
approach has been followed. Due to non-existence of a central 
agency to provide overall ADP management, each of the major 
NATO commanders tries to develop his own system, SACEUR for 
example has organized a project office to design and implement 
command and control ADP information system for his headquarters 


in Belgium. [3] 
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eco ole OF SYolteEMS DEVELOPMENT 


te GENERAL 

A major computer application, as is the development of an 
automated tactical real time system, constitutes a complex, 
mime secOonsuming and costly process. Due to the complexity in- 
volved, this process, by which the automation proposal is trans- 
formed from a conceptual idea to a sound reality, has to be 
approached via systems analysis techniques. 

Systems analysis is a methodology by which facts about a 
system and the environment, in which it operates, are collected, 
organized and evaluated. The objective of systems analysis is 
to examine all aspects of the system-equipment, personnel, 
Epepstings conditions and its internal and external demands to 
establish a basis for designing and implementing a better system 
in the best cost/effectiveness combination. [26 ]| 

PoWmEMempiueposes Of this study, the activities involved. 

Bre organized according to eight distinct phases of system 
development: [25, 26] 

* Definition Study 
Preliminary Design 
Detail Design 
Preparation of Request for Proposals (RFP) 
E aaron Of Vendor Proposals 
Emos pan and=iiumam Job Development 
Testing 


Operations and Support 
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The organization of these stages identifies the basic 
milestones and divides the developmental effort into manage- 
able segments. Specific information must be created in one 
stage before the next can proceed. The principle of concurrent 
development may be executed within a stage, but should not be 
employed across stages, for the simple reason that different 
stages Operate at different levels. 


Figure VI-1 illustrates the System Development Phases. 


EE roo PHASES OF SYSTEMS DEVELOPMENT 
I. Defimircion Study [26] 

The primary purpose of the definition study is to trans- 
form broad problem statements into precise statements of objec- 
tives and to resolve questions concerning the feasibility of 
developing a system to meet these objectives, before committing 
a prohibitive amount of resources. 

Definition study should include the following activities: 

—Setinition of the Problem 

The existing problem is stated as clearly as possible. 
This will enable a common interpretation to be maintained from 
the outset and through the developmental and implementation 
Belges. 
* Establishment of the study scope 
The scope of the study effort should include a clear 
Statement of the objectives of the study, any restrictions placed 


upon it, the composition of the study team, the study milestones 
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and the corresponding times by which they are to be accomplished, 
Meco ren ot the final report and the resources to be used. 
* Analysis of existing methods and procedures 
Information about the existing methods and procedures 
are gathered and analyzed, existing problem areas in the system 
are evaluated and suggestions for improvement to the system 
are made. 


eta 
ae 


Development of system objectives and establishment 
o men ormance criteria 


The needs of the Service are translated into clear ob- 
jectives or requirements to be satisfied by an operational system. 
they are generally a statement of prime results the system is to 
accomplish. They should be identified in sufficient detail, in 
order to permit a measurable level of performance to be prescribed 
for the system design. A preliminary set of objectives can be 
developed by using estimates of the output characteristics, 
which can be derived from descriptions of user activities, such 
as information requirements of the Service, means of expressing 
mer intormation, frequency accuracy, quantity, etc. 

The performance criteria are identified and stated in 
a manner demonstrating how the system will contribute to, and 
enhance the overall organizational objectives. 


Determination of resources, constraints, assumptions 
SndmliGems for resolution 


All resources, constraints, assumptions and items for 
resolution are identified and evaluated to determine their effect 


on the new system. 
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Resources are the capabilities available in building 
the system and include hardware, software, personnel, facili- 
ties, modes of expression (charts, tables, codes, etc.) and 
finances (estimates of costs for implementation and operation). 

Constraints are the limits of the resources in terms 
of resource capacities. 

The assumptions are based on considerations such as 
Af torical studies, Service background, industry standards, 
general statistics, empirical evidence, etc. 

Items for resolution are those questions or problems 
that must be answered or agreed before the system development. 


MANS is Of system outputs, inputs and major functions 


All system outputs and inputs are identified and 


analyzed. This analysis will indicate the major system func- 
one tanda data Organization. During this activity, only a rough 
outline oí the functions that must occur is given. More detailed 


specifications are developed during the preliminary design, 
transforming functions (what must be done) into processes (how 
EE done The functions identified at this time, usually 
Acne ea tesories of input preparation, input validation, 
data base maintenance, information retrieval, output handling 
ic 


Determination of System capability requirements and 
potential approaches 


The major system functions and data groups are ana- 
lyzed to determine general system capability requirements (e.g., 


data base storage and organizational requirements). 
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Based on these requirements, a number of system ap- 
proaches is developed. The purpose in considering a number 
of alternative approaches is to determine a configuration ap- 
proach, that is most favorable on a cost/effectiveness basis. 
* Evaluation and selection of system approach 
The approach of the previous activities are evaluated 
objectively and selection of the approach, which provides the 


same, Or better performance at lower cost than any of the others. 


Determination of the types and magnitude of expected 
implementation and conversion requirements 


In many systems development efforts the problems of 
implementation and conversion are of paramount importance, re- 
quiring in some cases expenditure as the rest of the system 
Sort in total. 

The requirements of implementation and conversion 
must be fully understood and explicit at the definition stage 
and appropriate techniques developed for the resolution of 
Problems. 

At this stage however, only a rough assessement of 
the manpower resources and the time required for this effort 
are made. More detailed examination will be undertaken at 
the Design Stages. 


Preparation of the overall plan and cost/benefit 
analysis of the proposed system 


The overall plan is derived from the system objectives 


and from the overall structure of the selected system configuration. 
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This plan will identify those processes necessary to build a 
system, which will meet the system objectives for the system 
approach recommended. 

The construction of a cost picture of the proposed 
system is based on the best estimates available. At this stage 
the cost figures will be rough, but reasonably accurate. The 
estimation of benefits is often more difficult, especially 
since many benefits may not be quantifiable (e.g., the destruc- 
tion of an approaching missile). In such cases the quantified 
costs must be applied to benefits that cannot be expressed in 
terms of relatable quantifiable savings. 

Preparation of the Definition Study Report 

The results of all the previous activities are sum- 
mebized in this report, which is considered as a final techni- 
Sal report. 

TeS report vill be the "base line" for further 
system development. 

2. Preliminary Design [26] 

This stage provides the transition from a definition 
of system approach and objectives to a fully designed system 
EEoswesrnon. This system specification consists of a preli- 
minary design of the entire system, including hardware, soft- 
Ware and personnel subsystems to the point where programs and 
procedures may be designed and hardware may be ordered. 

Considerable effort and money will be spent during the 


design period. Experience has shown that the final product may 
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daittrer significantly from the initially defined product. It is 
therefore desirable to arrive at a preliminary design milestone, 
before the design is completed in every detail. In this manner 
the design can be changed, if necessary, before further detail 
is developed. 

The result of this stage is the Preliminary Design Report. 
The report will provide the Service with concise information 
necessary to decide on whether to continue the system development 
ELO DE. 

The activities included in the Preliminary Design Phase 
are the following: 

Specification of system expansion requirements 

The initial system design should be examined from 
the standpoint of what may be required after the system has 
been Operational for some time. 

Two approahces are considered in order to ensure sys- 
tem expandability: 1) design the system with considerable over- 
capacity built-in, 2) design the system to accommodate the 
immediate future load, but with easy upgrading techniques in- 
cluded in the design. 

Normally a combination of the two approaches is preferable. 

Definition of the overall system capacity 

In this activity the hardware and software environ- 
ments required to enable the system to meet the objectives 
are specified. This will lead to decisions for providing 


capabilities, that are lacking or, where this is not feasible 


to changes in the systems objectives. 
va 








The following requirements should be considered, when 


defining the system environment: 


(1) Applications requirements 


(2) 


e) 


(4) 


multiprogramming/multiprocessing 
batch processing (remote) 

demand processing (time sharing) 
real time processing 


processing time-frame and load 


Data communications requirements 


number of data sources and points of distribu- 
eioan their locations 

volume and response time of collection and 
distribution of data 

number and type of terminals 

degree of accuracy and penalty for system 


Pa ieee 


Data Base requirements 


SUE CUNG 

access methods 
organization 

recovery and fall-back 


Security 


Physical facilities 


la lesanceded and Cheir locations 


existing facilities 


Description of Subsystems 
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A description of the system segmentation is prepared, 
together with a functional description of the processing re- 
quirements for each subsystem. 


Development of subsystem input, output and interface 
requirements 


Input/output requirements are determined by analyzing 
the system processes occuring in each subsystem. The subsystem 
designers interact to combine their respective input and output 
requirements into subsystem interface records. The interfaces 
represent the degree of subsystem interaction and data flow. 

The data catalog is established at this time and will 
be maintained and updated throughout the life of the system. 
This catalog lists all the data items used within the system, 
using standard name and number. Associated with these items 
will be the processes and files, that use the data items as 
the processes and files are developed. 


Preparation of system/subsystem flowcharts 


A process is the logic of how a particular set of 


functions within a subsystem is performed. This logic is most 
conveniently described in terms of a flowchart. This descrip- 
tion will vary between a batch and a real time system. For 


a batch system, the actions will be grouped into a process 
according to a similar logic and intermediate results for inputs 
or transactions passing through the subsystem. For a real time 
System, an individual transaction is described by a string of 


Specific actions, which that particular action requires. 
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Develop process descriptions 
The processes identified on the system/subsystem 
Aee hart are expanded into descriptive narrative detail 
Narratives support the flowcharts providing details and 
explanations. 
* Specification of system protection requirements 
This activity specifies appropriate corrective action 
mieeases Of failure error or compromise within the system. 
zeNdentrirtyceation of human engineering problem areas 
All areas, where human engineering is required to 
Optimize personnel effectiveness, comfort and safety, are 


Ncentrfied. 


Design of logical data base structure and definition 
of the access techniques 


The records currently being used by the existing 
system are evaluated against the information requirements of 
the new system. This results in the selection of records to 
be used for generating the data base of the new system and in 
the establishment of a data base structure and a system for 
retrieving the data in the manner required. 

At this stage the designer is primarily concerned 
with the logical structure of the data base, that is, how it 
will be seen by the programmer and user. Similarly the logical 
accessing methods (e.g., chain, list etc.) are described now. 

Specification of data communications requirements 

All the communications equipment and facilities 


required by the operational system should be identified.  Com- 


prehensive specification for the relevant communications network 


are developed. 
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In the specification of the communications require- 
ments factors, such as the availability of existing communica- 
tion facilities (lines, microwave, etc.), loads (peak, average), 
future expansion in traffic load, should be considered in order 
to calculate trade-offs between capacity and cost and in order 
to make necessary design adjustments. 

Various forms of networks should be considered. 
Packet switching, message switching, or centralized processing 
(star-shaped) configurations may all be possibilities. 

Specification of hardware configuration 

Panels aetivity, the hardware configuration is 
specified. Processing requirements should be calculated and 
CPU and I/O device requirements should be determined. These 
requirements will be used to determine the CPU size and neces- 
sary speed. The general characteristics of the I/0 and data 
base devices must be also defined. 

The hardware should include: 1) central processor, 
2) support processors, 3) core modules, 4) I/O devices, 5) 
channels, 6) mass storage devices, 7) control units, 8) peri- 
pheral devices, 9) special purpose devices (e.g., modems). 

Specification of system software 

Dan nge this activity, the software Characteristics, 
which will be required to support the designed system, are 
specified. Some important software components are: 

- Operating System (partitions, multiprogramming/ 


multiprocessing, roll-out/roll-in, control language, 
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ftasiestites, hardware control, compatibility, interrupts, 
Pppedrlan, system generation, priority assignment and control). 

- Languages (high level languages to be used, report 
generator, assembler, special purpose). 

- Management software (data management, communica- 
Bons henealers, transaetion processing, real time, time sharing, 
miscellaneous packages). 

- Utilities (sorts, merges, data transcription, file 
maintenance, debugging aids, error handlers, checkpoint, account- 
ico tines: dumps, labeling routines, copy routines, extracts, 
conversion routines, program maintenance routines). 

- Special software (statistical packages, other 
mathematical packages, etc.). 

Preparation of development and implementation plan 

A more detailed plan, than the one developed in the 
Pen itron tetudy. is prepared during this activity. It should 
describe, in detail, the activities for the remainder of the 
effort, inciuding all milestones and manpower requirements. 
Several methods, such as PERT charting may be used. 

Preparation of the Preliminary Design Report 

This activity produces a report with the most accurate 
and complete picture of the system, using the up-to-date infor- 
mation available. | 

After revision and approval, the Preliminary Design 


Report becomes the base document for future development. 








De tall Desten [26] 

During this phase the preliminary system design is 
expanded and refined to produce detailed specifications for 
all program modules, manual procedures, and information files. 
The resultant specifications are precise, explicit and in 
sufficient detail to support the next phase. This means that 
all computer logic, data base organization, hardware/software 
specifications are completely specified and documented. 

The activities included in this phase are as follows: 

Peret pnentriot human procedures 

A series of statements, that establish a course of 
action to be followed consistently under stated conditions. 
They instruct personnel in their responsibilities and they 
improve performance and organization. 


Design of manual forms and computer input/output 
interfaces 


Here the design of all manual operating forms is 
completed, including all subsystem written communications, 
except those which exist as computer interfaces. 

Furthermore, the design of all computer interfaces 
to human procedures is completed, considering the human engi- 
neering factors of emphasis, legibility, alignment, spacing 
and brevity. 

Design of physical data base 

This activity consists of synthesizing the require- 


ments of the logical data base, specified hardware, data 
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management, hardware requirements and the user-processing 
requirements into an optimum implementable whole. 

During this activity the required data base items 
are grouped into physical data record formats. 

Design of subsystem protection features 

During this activity, those requirements for level 
of protection (already specified in the Preliminary Design), 
which are supported by subsystem design, as it now stands, 
are translated into a form design. Features requiring design 
may include failure isolation, fall-back, recovery, data base 
Breonstruetion, data privacy, data integrity, facility security, 
hardware reliability. 
* Definition of subsystem programs 
During this activity, the processes to be performed 
in the subsystem are combined and/or subdivided into program 
descriptions. This grouping is normally done on the basis of 
logic similarity, data requirements, function sequence or some 
combination thereof. 

* Development of logic flowcharts and tables 

In this activity, the logic of each program module 
oa dotan graphic form. 

Specificatiom Of software utilities and common routines 

Mins activity programs and program modules are 
analyzed to determine the possibility of replacing them with 


utility software, in order to reduce programming effort. 


TR 








ep -eeuteattonec: data communication requirements 

Pie thts seetiviny all Goemmunications equipment and 
facilities required by the operational system, should be identified. 
Mieasewneeds are then refined, combined and adjusted to develop 
comprehensive specifications for the communications network 
required. 

^ Development of subsystem test plan 

Dos activity a test plan is prepared to satisfy 
those specifications established during the design activities, 
expanding and detailing previously defined test requirements. 

The plan should include schedules, desired results, 
evaluation of results, configuration required (core, disc, tape 
drives, etc.), volumes to be used, duration, varlable require- 
ments, time and manner simulation is to be used, personnel 
required, processes to be tested (manual and machine). 

* Preparation of Detail Design Report 
After all detail design activities have been com- 
pleted and the system design is agreed upon the Detail Design 
Report can be prepared. Beyond describing the ststem as it 
currently stands, the report should highlight those changes 
introduced during the Detail Design, that will have impact on 
the system's planned performance. 

u. Preparation of Request for Proposals 

During this phase the Detail Design Specifications are 

communicated to the vendors, who are invited to participate in 


a competitive procedure of offering their products and services. 
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5. Evaluation of Vendor Proposals 
In this phase the proposals of the vendors are evaluated 
on criteria established in the RFP document. The most cost/ 
effective proposal is selected. This stage culminates with 
HESS cuc ward. 
Hos rs an indicative list of criteria, on which 
vendor proposals may be evaluated: 
* Personnel support 
Mie numbers and qualification of analysts and pro- 
grammers are examined. 
Performance on Benchmark Programs 
The performance on benchmark programs for single 
job and multiprogramming is evaluated with respect to time, 
equipment needed, O/S needed and reliability shown. 
* Programming 
Factors such as ease of programming, language features, 
compilation speed, compiler diagnostics, execution diagnostics 
and program size, as they were determined from benchmarks, are 
considered. 
* Operating System 
The resident 0/S system is evaluated with respect to 
components (Scheduler, Memory Management, etc.), Resources used 
(Storage Devices, CPU Time), Maintenance required, Partitioning 
of programs between internal and external storage. 


de 
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eneckoue Tacrlrties provided 
The place, time, duration, hardware configuration and 
avallable software of the checkout facilities provided, is considered. 
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Ereeram Conversion 
The capabilities with regard to Conversion from 
Language A to Language B, cleaning up of incompatible commands, 
emulation and rewriting of prograns are examined. 
* Test Tools 
The existing test tools (debugging packages, test 
data generator etc.), are considered. 
File Conversion 
Mretcaipabllities for filegeanversion with respect to 
program conversion, support provided and Media/Format conver- 
Eton are checked. 
* Documentation 
Mae atina documentation with respect to Programs, 
Operating Instructions and Maintenance, is evaluated. 
* Physical facilities required 
Es mec ael cies required, such as Space, Electri- 
ea Air Comditioning, are examined. 
* Training provided 
SR Uentiey and quality ofthe training provided, 
with respect to programmers, computer operators, data operators, 
is carefully considered. 
Beeküp facilities 
The number of backup facilities in the area and at 
Dane rezscompared. 
Acceptance tests 
The time, location, duration of acceptance tests, 
as well as the specific test programs are examined. 
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Vendor record 
mesper ormnance, hardware reliability and the support 
of the vendor are examined. 

ivseeraci.On schedule 

This schedule with respect to hardware installation, 
program and file conversion and turnover are considered. 

Expansion Capabilities 

The expansion capabilities provided with regard to 
hardware and operating system are compared. 

costs 
Relevant costs regarding hardware, software, people, 
maintenance and other services are examined and compared. 

6. Program and Human Job Development [26] 

The purpose of this phase is to covert the completed 
design into executable manual jobs and computer programs, which 
can be tested subsequently. 

In practice, this phase is devoted to the process of 
verifying the program specifications produced in the Detail 
feeeenemoducing coding diagrams, coding the programs, com- 
Diling and desk checking the programs and finally debugging 
BE Dospasms to the point at which they may be turned over to 
those responsible for System Testing. The process is normally 
the responsibility of the programmer, who is the author of a 
particular program. 

Any methods of saving programming time and cost, such 


as automatic coding, program generation, desk debugging, 
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flowcharting and documentation aids should be considered and 
applied, whenever possible. Special care should be paid in 
the case of multiprogramming and multiprocessing, due to the 
increased complexity of the programming effort. This is also 
true of programming for communications systems. 

Program Development includes the following activities: 
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Synthesis of position descriptions for personnel 
subsystem 


In this activity the procedures developed in the 
Detail Design are grouped into position descriptions for 
personnel. A position or job is defined as the workload 
asSigned to one man in the proposed system. There may be one 
or more procedures involved in one personnel position descrip- 
tion or one procedure may be divided into several positions, 
depending on the size and complexity of the procedures. 
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Establishment of personnel and environmental 
requirements 


bucne this activity, initial. estimates are made of 
the types and numbers of personnel required by the system. A 
training plan should also be prepared to include: 1) system 
Prrencarion at all levels, 2) specific position training, 3) 
Bross position training. 

In addition, detailed human engineering specifications 
are prepared for those system operations, which require the 
presence of people. 


Development of detailed prosram flowcharts 
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Mts a etiyvity joptiepal in some cases, provides. for 
the detailed flowcharting, that will approximate the instruc- 
tion level and be complete enough to guide the coder in the 
performance of his task. 

Coding of Prosrams 

Bauesseetivity ineudes the coding of theprograns, 
using the specified language for this purpose. The most im- 
Perrant control for ensuring good coding is to have a compre- 
hensive and useful set of coding standards, plus a method for 
ensuring that these standards are followed. 

It is very inportant that consistent and effective 
use is made of comments. Each routine shouid have at least 
a brief explanation. 


oe 
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Preparation of source decks and compile/assemble 
programs 


HE cvi Ineludes che completion of coding to 
a final, fully prepared source deck, which together with the 
necessary control cards (compiler control cards, source image 
library control cards, special purpose control cards), is 
submitted for compilation/assembly. 

After each compilation/assembly, the programmer 
EnmudEsspefutv check the output produced for errors. 

When correcting discovered errors, particular care 
should be taken to ensure that new errors are not created. 

Preparation of program (module) debug data 


The purpose of these data is to: 1) execute every 


routine, 2) execute every instruction, 3) remove the inherent 
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bugs created during coding and source preparation, 4) test 
Moan tes of arithmetical and edit instructions, 5) test the 
S@@ecetness Of the internal program (module) logic. 

GinesmeSpensi bility for this activity belongs to the 
programmer. The methods of preparing debug data include singly 
Erzıinseombsnmation branch point analysis, general analysis, test 
Are enerators and samples from existing files or inputs. 

Debugging of Programs 

This activity begins after a completely coded program 
has been compiled without error and job control is complete. 
The program may consist of one or more load modules. All pos- 
Sible functions and conditions, contained in the program must 
Bbewecnecked out, utilizing the branch point analysis chart pre- 
pared in the previous activity. Here it is where the rigorous 
debugging of an individual program occurs. 

Wns se che stage Of testing, where every instruction 
Within the program is exercised and where the verification of 
internal consistency within the program is made. 

* Preparation of Program and Human Development Report 

Por ineserhis activity, the documentation must be 
revised to ensure that the description of the system continues 
to be accurate and complete. 

All changes made to the system, during this stage 
should be identified and their impact on the overall system re- 


assessed to ensure that they are consistant with the overall 
system objectives and that they have caused no performance de- 
gradation, when related to any portion of the system. 
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The final report should subsequently be prepared and 
should include a section for personnel related information and 
a section for program (module) related information. 

EE n eS | 

Testing is the phase, where the validation of all sys- 
tem components occurs. It constitutes the basis for accepting 
a System and its completion represents one of the more signi- 
ficant milestones. Testing at any level may result in the re- 
desin Of a portion of the system. 

INES Lente Of testing isone Of the most critical points 
during the system life cycle and one that frequently causes 
the most troubles and lost time. 

MEN” pea” activities included in testing are as 
follows: 

Development of detailed test plan and procedures 

Even though extensive test planning was accomplished 
in Detail Design, a more detailed planning will be required 
eens pOimt bys those responsible for conducting the tests. 

A detailed test plan is prepared for testing, as a 
whole and for each identifiable test that will take place. 
Furthermore standard procedures, such as "always dump core”, 
or "always write out register contents", when a program halts, 
must be prepared. 


Preparation of site and installation of hardware 
and facilities 
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hes is thes latest point in time for this activity 
to take place. Any delay in the preparation of the site or 
installation of hardware can disrupt the entire schedule. 

Peveole@pnen= On VObmceream and job control 

In this activity the designers, responsible for job 
stream preparation and those concerned with system performance, 
will develop the best operational arrangement for program modules. 

Job streams are the linking of program modules into 
executable sequence. Implicit in the development of job stream 
is the development of the job control, since this is usually 
the only way of defining the load module structure and attendant 
factors. 

* Test training courses, work aids and human procedures. 

Previously developed training programs are tried out 
on groups of people in prectice training environment. 

work aids are exercised to determine whether they 
support the task, as anticipated. 

All human procedures that were completed in the 
Detail Design are validated in simulated work environment. 

* Build test data base and transaction files. 

Bee era Cratical activity, as the entire testing 
of the automated system and future reliability of that system 
will probably related to the adequacy of the test data used. 

The employment of an automated test data generator, 


either as an "in house" product or as an outside service should 


be considered, especially in large system efforts. 
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The importance of the test data base cannot be over- 
Seressed. Enough data must be used to create the anticipated 
operational conditions and enough volume to cause an overload- 
ing of the system. An inadequate test data base could lead 
to the acceptance of a system, that could not survive under 
loaded operational environment. 

Test transaction files should be created either through 
a test data generation or by collecting a representative sample 
of live transaction. Coordination between the test data base 
and the test transactions is required. 

* Test subsystem/system. 

Subsystem testing includes a careful testing of a 
Pegerameim rts environment, that is, the adjacent programs. 

For batch systems this includes job stream testing. 

For on-line or real time systems the process is to 
test the transaction paths, which involves exercising all 
programs or processes required for a unique input transaction 
pe. 

In this activity the project team creates and executes 
a test procedure to ensure that the completed subsystem can 
operate without disturbance, its performance is up to standard 
and that it meets the objectives originally set forth. The 
work load will be as in a normal work day and will then be 
expanded to overaload conditions. 

The objectives of the subsystem testing is to detect 


deficiencies not found in debugging and to assure, that the 
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os ys tembwill function as required under conditions closely 
related to those encountered in the operational environment. 

Once subsystems have been independently tested, they 
must be brought together into a system test. This step is con- 
cerned with the testing of all relationships between subsystems 
and of the relationship between the system and the outside 
environment. 

* Performance of acceptance test 

Pam nesschis aeeivıty it 1s verifled to the user, that 
the system meets the system objectives and performance criteria 
and is operationally sound. 

In a small system it is possible to conduct this step 
immediately after implementation. However in large systems 
the process of conversion and implementation is so large, that 
it is appropriate to ensüre the workability of the system before 
undertaking an expensive and possibly useless implementation 
and conversion. Successful completion of acceptance test is 
ac mserikerıon for final turnover of the system for 
NunNEnenedpRon. The acceptance test should be therefore 
thorough and complete. 

Preparation of the Test Results Report 

The test results report is a final technical report 
that should reflect the testing phase. 

3. System Operation and Support 
This phase represents the normal operation of the system 

after its implementation and continues as long as the system is 


men aımed operationally. 
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The activities required during this phase include: 
(MB eae operation task [26] 
* Establishment of implementation control plan 

A detailed implementation plan is prepared to 
include solutions to problems identified during testing in the 
areas of hardware, software and man/machine interfaces.  Com- 
pletion of materials required for implementation (user guides) 


and operation (work aids) and turnover of the implemented system. 


Training of operations and maintenance personnel on 
hardware, software and the new system 


Proper attention should be given to personnel 
training on hardware, software and the new system, to minimize 
the impact of operator's error during the operation of the new 
system. 
* Turnover of system and documentation of implementation 
This activity summarizes the implementation effort, 
which culminates when the turnover of the system to the opera- 
onal personnel occurs. 
Developing and monitoring critical indicators 
Certain critical indicators are established and 
monitored, to provide advance warning of conditions, which may 
cause system degradation or collapse. 
* Scheduling of computer operations 
The scheduling of computer operations is completed 


in accordance with the operational demands and resources 


available. 


140 








Prevention and recovery from run failures 

Precedures for the prevention and recovery from 
run failures would be established in order to insure smooth 
functioning of the system and minimize repair time. They should 
be derived from the design and programs for fallback, recovery 
emma correction. 
* Monitoring disaster control and security plans 
Disaster control includes all measures required to 
avoid the loss of software, beginning with alternate storage 
e all programs. 

Security control regards all measures, that should 
be taken to prevent unauthorized access or sabotage. 

ORo ehe maintenance task 2 

The software of real time tactical systems is one 
of the largest and most complex applications software in exis- 
tence today. Naval tactical software provides the control of 
Ace rronle sensors and displays, computations of tactical and 
navigational algorithms, control of weapons and ordnance and 
real time response to man-machine interface demands. These 
automated tasks are performed by software for the purpose of 
accomplishing naval mission requirements and pursuing objec- 
tives of Navy interest. 

In order to accomplish the support taks, an "in house" 
Software Management Organization should be established. The 


organization should begin with the highest echelon of command, 


which will establish overall objectives and provide funding 
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ads include appropriate organizational divisions to carry out 
the required tasks. A Work Breakdown Structure might be as 
follows: 

Project Management 

Provides direction, plans and schedules. 

* Configuration Management 

Broyardeeseonfisunation baseline control. 

Quality Assurance 

Provides verification and validation. 

De ociwycre Production 

Provides engineering analysis, design, code and debug. 
Laboratory Facilities 

Provide operation and maintenance, generation, integra- 
Eton and training facilities. 

The support phase is the key to the ability of the Navy 
for maintaining the readiness of its software in the face of 
changing threat conditions. 

The maintenance task begins at the time the software 
is released to the Fleet for operational use and remains in 
effect as long as the specific tactical real time system is 
in operational use. During this phase, Fleet users submit 
requests to the Software Management Organization for software 
modifications, which result in periodic updates and reissues 
of functionally improved software. 

The support task minimizes the obsolescence of the plat- 


forms (ships, aircraft), on which the system has been installed. 
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Because the platforms are programmable, it is possible to 
recode portions of the software and to create new functional 
Eepabrtıties. In their use of the platforms, Fleet operators 
may determine many unique improvements to the operation of the 
platform. Many of these improvements can be implemented via 
software or as a software work-around for a future hardware 
change. 

Periodically, but not frequently, the Navy can make 
major hardware revisions an/or additions to a platform. 

Through periodic software re-issues (say 1 to 1% years), 
the Fleet can obtain system improvements and thereby increase 


tactical proficiency, in order to handle dynamic threat conditions. 


BE STRUCTURING THE SOFTWARE BASE [28] 

iMWemsortwane base 15 Structured; in part, by partitioning 
the software tool types according to the specific development 
Meetyities they support. In order not to ignore that part of 
the software base, that supports the operation of such tools 
and to indicate clearly those tools which support more than 
one activity, the software base is structured further through 
a layered approach, that provides insight among the software 
base components. 

There are at least five distinct virtual layers, associated 
with an operational computer system and three layers of soft- 
ware, that support the software development process. Layer O, 


the innermost layer, represents the bare computer hardware, 
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including items such as processors, channels, main storage, 
mass storage, bulk I/0, archival storage, hardware monitors, 
terminals, sensors and communications interface devices. 
Layers l through 3 "reside on the hardware and collectively 
provide the virtual machine capability, that is necessary 
to support layer 4, the applications software. 
The following paragraphs provide a short description of 
Ei" ceps 1 through 3 along with a listing of the tools, that 
reside on those layers and the relationship of such tools to 
the various development activities. A concise description of 
each tool is provided in the glossary section of this study. 
IN cr: Functional Stipport Tools 

Layer 3 contains those tools, that provide direct sup- 
port to the activities of the software development phases. 
These are the tools with which the applications software devel- 
oper has the most interaction. Layer 3 tools are related to 
the specific development activities they support. 

Tools sunportine Phase Il (Definition Study) 

The types of tools that are directly applicable 
to requirement analysis are listed below: 
* General Purpose Simulators 

System Description Languages & Analyzers 


Be ole supporting Phases 2 6 3 (Preliminary and 
Detail Design) 


The types of tools that are directly applicable 


to software design are the following: 
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* Computer System Simulators 
* Data Base Design Aids 
Ita Donar system 


SACO ES = euppörtıns the activity "Development of 
test plan" in Phase 3 (Detail Design) 


The types of tools required to support system test 
onstruction are listed below: 

'" Test Data Generators 

* Test Data Auditors 
Test Case Design Advisors 
‘ Test Instruments & Analyzers 


d. Tools supporting Phase 6 (Program Development) and 
Activity "Testing Subsystem" of Phase 7 (Testing) 


The types of tools required to support the program 
development and the subsystem test activity are listed below: 

* Assemblers 
* Compilers 
Linkers 

' Debugging Aids (Interactive Symbolic Debuggers, 
Non-Interactive Symbolic Debuggers, Interactive Absolute Debug- 
gers, Non-Interactive Absolute Debuggers) 

* Module Libraries € Change Control Systems (Basic 
Libraries, Integrated Libraries, Automatic Software Production 
& Test Systems) 

* Performance Monitors (Language Dependent Monitors, 
Language Independent Monitors) 


2h 


Standard Enforcers 


Je 
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Preprocessors and Reformatters 
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e. Tools supporting Activity "Testing System of Phase 
7 (Testing) and Phase 8 (System Support) 


There are no unique layer 3 tools that exist to 
support these activities. The tools, that were listed to 
support the aforementioned phase and specific activities, are 
generally applicable. Most of the tools used in practice, that 
are specifically oriented to system test activity, are special- 
Purpose, e.g., test environment tools (Emulators, Hot Benches, 
System Integration Lab. support, virtual machines), test drivers, 
and special purpose monitors. 

2. Layer 2: General Support Services 

The primary function of layer 2 tools is to provide a 
framework of common services, that will allow the output of 
the third layer function to be stored, retrieved and inter- 
communicated. Second RT E should be usable for 
common purposes across different third layer functions and 
should serve to hide (where possible) differences between first 
layer and third layer functions. Layer 2 tool types provide 
general support to all of the software development activities. 
These tools are listed below: 

* Data Base Management System 
* PERT/CPM Systems 
Project Estimation Systems 
Documentation Aids (Text Processing Systems, Flow- 


charts Construction Languages and Automatic Flowcharters) 


Data Manipulation Utilities 


Information Retrieval Systems (Query Language System, 


Report Writers) 
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3. Layer 1: Operating System Services 

Layer 1 implements the operating system services, that 
present a "virtual machine" interface to the services/tools 
at layers 2 and 3 and manage the real time hardware. The 
layer 1 tool types are generally applicable across all of the 
software development activities. Layer 1 tool types are listed 
below: 

* Basic Operating System (BOS) 

* Multiprogramming Operating System (MOS) 

* Multiprocessor Operating System (MPOS) 
uut fcnise Monitor MM) 


* Time Sharing Operating System (TSOS) 


* Real Time Operating System (RTOS) 
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MO MECO IDERATIONS 


A. GENERAL 

While not directly involved in the technical performance 
of a computer system, cost is perhaps the most significant 
factor in procurement and can overwhelmingly dominate perfor- 
mance specification, evaluation and contractor selection. The 
cost elements are at least as complicated as the technical 
aspects. It is important that the purchaser have a good know- 
ledge of the entire spectrum of costs, related to a computer 
system, or the cost can rapidly escalate beyond his resources.[29] 

Basically, the costs of a computer system fall into two 
Broad categories: 
* Hardware costs 

Someware costs 

In general, it can be said that software costs rapidly out- 
grow hardware costs. Two reasons are behind this trend: 

* The reduction of hardware cost due to the advances in 
BU aEtonputer Electronics Technology: 

Three major factors are considered as pivotal to com- 
puter/processor development: 1) density, 2) speed, 3) cost. 
Pebrplet consideration of these factors is necessary to explain 
the reduction of hardware cost with the advance of technology 

Dr. Gordon Moore (founder of Intel Corp., with Robert 


Es sc uoted in 1964, that the density, or number of components 


Pesechip (Circuit) had doubled every year since 1959. Moore 
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further predicted, that this trend would continue. Moore's 
Purves 25 illustrated in Figure VII-1, appears to be continuing 
its trend, supported by technology. This curve is the basis 
for predicting the future of computer/processor, since most all 
characteristios of the computer/processor can be related to 


density with a high degree of confidence. [23] 
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Pie ARS BUCEO timing of a computer/preocessor (or 
iiversely the numbem of operations or throughput, that an 


architecture can expect) is related to density by the relation:[Í29) 


i 0.448 


cS B NU 
d e 
D 
z DS 
where: 
BEN time to execute an average instruction (us) 
Ne ze numbersorreircuirts 
m meocEBed3rtyon coertjcient 


Evidently, as the density increases, the processing 
capability for a given volume or weight improves, as indicated 
NnNcore's curve. 

The cost of a computer/processor is related to the 


ems ty by: [29] 
05795 


L4 - SE N_ (VII-2) 
r^ = 0.965 
where: 
E - cost of hardware in dollars 
N A umberocot e»peusts 
r? = correlation coefficient 


Therefore it can be said that the computer/processor 
can be related to throughput with the above relations VII-1 
ama Vii=2 . 

If the cost to produce N, (Humbert cirenuats or chips) 
goes down, the cost of performance (or throughput = = AS) 


will decrease also (see Figure VII-2). 
NS) 


a a a ae AMT nem 








metele ve tot Figure VLl=3 protrays the trend of silicon- 
device prices that dominate the costs of circuits, dominating 
pomputer/processors. This curve is used as the basis of trend 
Precjerions for the cost projections of Figure VII-2. 

The general trend, that is obvious, is that an order of 
magnitude improvement is seen in the cost versus speed relation- 
ship every ten years. [29] 

Theweentinuing escalation of software costs. 

Both the major phases of software life cycle, that is, 
software development and software maintenance, are contributing 
to this cost escalation. 

Software is generally on the critical path of system 
development. Any slippages in the software development schedule 
translate directly to slippages in the overall delivery of the 
system. Software development tools are also expensive. A new 
architecture may involve software tools in order ot $24 to $28 
million. A decision to use a new architecture, with a result- 
Be häisher program costs, can skyrocket the software costs, 
even though the cost per instruction may seem an insignificant 
percentage. 

Software maintenance costs are even more high and will 
continue to escalate as long as there is a continuing addition 
to the inventory of code via development at a faster rate than 
code is made obsolete. For example, on one aircraft computer, 
software development costs were roughly $75 per instruction, 


A o tenanee costs ran as high as $4000 per instruction. L32] 


Ju 








100 





~ 10 ! 
v 
x 
«4 
- 
-d 
O 
o 
Y. 
= 
a 
a 
I. 
Ol 
1960 1962 1964 1966 1968 1970 1972 1974 976 
YEAR 
Figure VII-2: Trend of silicon device prices. 


no 








Figure VII-3 portrays the software life cycle cost 
breakdown on four large scale software activities, while figure 
VII-4 illustrates the hardware/software trends in the time 
Sram 1953 to 1985. [32] 

Estimates of the overall annual cost of software in the 
United States alone range from $15 to $25 billion. 

U.S. DoD spends an estimated $3 billion per year. Some 
Ire: Cent of the U.S. Air Force budget ls in computer 
software. 

It is important that the magnitude of the above figures 
are realized, when a trade-off decision is to be made between 
hardware and software costs, where either is impacted by the 
other. A decision to use a new architecture with a resulting 
er program cost can skyrocket the software costs, even 
Meanie cost per instruction may seem an insignificant 


percentage. [29] 
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Figure VII-3: Hardware-software cost trends. 
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Br zeomputlerzeost 18 sısnificantly related to total 


investment in an architectural base by: [29] 


Cece Boe Gime) 
p? ener 0.2 
where: 
Di ES per instruction 
B, = total dollar value of architecture inventory (SM) 
r Ta aeo dence nl O0 = perfect) 


Figure VII-5 illustrates a comparison of the cost of a 


family of computers based on the above relation. 


$0 










- S 
z 40 oo 
9 Tn 
b= xi 
Q » 
2 
= 30 de = e 
v x ! = 
: 23$ 2 
v 20 © 
o 
bd M 
ox 
10 = 
z 
> 
O E A dos 
! Te) 1000 
INVENTORY ($M) 
Figure VII-5: Instruction cost vs inventory investment. 


154 
RE A AA A a A 








SEO TAL. LIFE CYCLE COSTS 
Picwe MpuLer resource life cycle cost for system i and 


Bmehiteeture j is defined as: [29,30] 


Ci = PE * Ae (VII-H) 
where: 

m - hardware life cycle cost 

B - applications software life cycle cost 


Specifically for a microcomputer system, the applications 


Sertware life cycle cost ASw;. may fan outweight the hardware 


J 
ieee cycle cost HW. (e.g., a microwave-oven manufacturer can 


J 
pena several hundred thousand dollars to develop a software 
program to run a computer costing twenty dollars or less). [20] 
For this reason the computer resource life cycle cost for this 
system has to be amortized over hundred or thousands of units. 


Therefore the relation VII-4 becomes for the case of micro- 


Beonputers as follows; [31] 


en (VII-5) 
1] 1] rare 
N: 
nere: J 
13 = number of systems 1 of architecture j produced. 
M an vare Life Cycle Cost 


a. The Computer Family Architecture (CFA) Life Cycle Cost 
The computer hardware life-cycle cost for a given 
system, using a specific CFA (ranging from mini to large systems) 


Ee ened as: [29,31] 


ERE a EEG) 


ee 











where: 


D = index of the system 

j = index of architecture 

= = number of systems to be produced for system i 
Lj = hardware Liberec yClemeoat, Pade tor wel 8e., ratio 


of total hardware life-cycle cost tohardware acquisi- 
Acoso aeo 15 assumed to be 2 for 


a UT year Lro yC le. 


E =) processor acquisition cost 

ur main memory acquisition cost (see Fig. VII-6) 

SM; Secondary memory acquisition cost (see Fig. VII-6) 
Maroc son acquisition cost. Prunerpally based 


on technology, the processor speed is a factor of memory speed. 
At present there are three technologies that dictate three 
ranges of memory access time: 

"Some 

* metal-oxide semiconductor (MOS) 

* bipolar 
Peeeecponaing costs are ranging freme0.1 cents/bit to 1.0 cents/ 
DAT. 

These technologies represent memory access time 
Wencdeenrocessor speedæ of from 300,000 IPS to 80 MIPS, as shown 
wM agure VII-7. 

Ihe processon dequisition cost for System i, 
using architecture j is defined as: [29,30] 


Bee Cr) 
13 i) Í 
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Figure VII-6: Cost vs memory size. 
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Figure VII-7: Access time vs cost (1975-1976). 
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where: 


K = constant relating to processor cost 
er = processor speed ratio 
Mr, = operating speed in millions of instructions ver 


second (MIPS) 

Equation VII-7 follows from a commonly cited 
relationship between performance and cost, namely: 

Performance = Constant * Cost $ 

To obtain a value for constant k in equation 
Bern CEA used the fact, that recent cost/speed data for 
several military processors seem to indicate that speeds of 
0.5 MIPS and processor costs of $48,000 are representative 
values; therefore: 


k = 48 * 10° / Giese uc 1 


y 

This value of k refers to 1976 processor cost 
Eee tes and 1t 1s reduced by e factor of 10 for 1985 cost 
estimates, based on an assessment of hardware cost reduction 
over the decade 1976-1935. 


Mc NESSUN eoORNCSSMEIOI a processor 


with pP, average instruction processing time is: [29] 


r 
2 k 
Cui r^ CO (VII-8) 
r 
P 
where: 

Cui uc Le Tc processor 
e Ges 0 
g = 0.4 
a - average instruction execution time (in ysec) 
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can Memory Acquisition Cost. Presently, there 
exist three types of main memory technologies, that is core, MOS 
and bipolar with distinct characteristics in access time, capa- 
ENSEy and cost. 
The main memory acquisition cost for system i, 


using architecture j, is defined as: [29,30] 


MM s a = m EMT + DM, ) (VII-9) 
where: 
MM: - main memory acquisition cost (in dollars) 
Diz = static storage ratio 
PM, = main memory (in bits) required for program i: 


M. is derived from system requirements; P is 
estimated fraction of Mi dedicated to program 
Storage yves data Storage. 

DM. = main memory (in bits) required for data stor- 
age in system 1; M; is derived from system 
requirements; D is estimated fraction of HE 
dedicated to data storage vs. program storage. 

e FP ee a a aaa menory. Examination or 
the price per bit of recent militarized equip- 
ment indicates an average cost of 4 cents per 
o AMOO par 16 000 by the 
memory module. This value in 1979 in the civi- 
lian sector is already .2-.4¢/bit and is ex- 
pected to be reduced by a factor of 10 (that 


1-002 0 eents per Dit) in 1985. 
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dee condary emo ry [Acquisition Cost. Inherently 
characterized by slower access time and enormous storage capa- 
city, secondary memories are important adjuncts to a computer/ 
processor. As expected, secondary memories have lower acquisi- 
pon cost. 
The secondary memory acquisition cost for system 
sine architecture j, is defined as: [29,30] 


M 
1] 


! 1 E 
C,(b,, P'Ma, + D'Ma,) (VII-10) 
where: 
SM.. = secondary memory acquisition cost (in dollars) 


a = static storage ratio 


ti 


P'Ma;= secondary memory Oinwesrkts) required rop pro- 
gram storage in system i; Ma; is derived from 
system requirements, whereas P' is the esti- 
mated fraction of Ma;, used for program 

j Storage vs. data ererage, 

Mae secondary memory MAD les). required for data 
storage in system i; Ma; is derived from sys- 
tem requirements, while D' is the estimated 
fraction of secondary memory, used for data 
Sera cee vs. plLeOgram Stordge. 

= = cost per bit of Secondary memory 

(See Figures VII-6 and VII-7) 
Eran trono ther pryce per bit sor current 


Militarized disc systems indicates an average cost of 0.2 cents 


p uc c a 36 Mbit dise system costs 972,000. This value 


NO 











used ın 1976 cost estimates; a cost reduction of 10:1 in 
the next 10 years is assumed, so a price of 0.02 cents per 
bit is foreseen in 1985 cost estimates (see also Figures 
VII-6 and VII-7). [29] 
(4) Measure of Performance Costs. [29,31] The pro- 
cessor speed E of equation VII-7 and the static sotrage ratio 


b of equation VII-9 above attempt to capture the ability of 


1] 
the jth architecture relative to the system i. They are derived 
by measuring the performance of the architecture j on benchmark 
test programs and by estimating the relative importance or 
weight of each of these programs to computation characteristics 
of each system. The performance of an architecture on test 
program is characterized in what are called the S measure 
(measure of Space) and the M and R measures (measure of Execu- 
tion Time) where: 

= is a measure of the amount of memory (in 8 
bit bytes) needed to represent test program 
k on architecture j. 

His is a measure of the processor/memory transfers 
required to execute test program k, when using 
architecture j. 

= is a measure (in 8-bit bytes) of the number 
of internal register-to-register transfers 


required by the processor to execute test k 


on architecture j. 


ao: 








For the Military Computer Family (MCF) project 
twelve benchmark test programs, as mentioned in Appendix G, 
were used for the derivation of E and DAE 

ive wine Tevaney On ene Kt nmasest mprOocram to the 
fem System is given by factors Wages which were obtained by 
First dividing benchmark programs into two categories: 1) 
programs that relate principally to I/O, and 2) programs that 
are associated with traditional processor/memory functions. 
Within these categories, varying degrees of functional overlay 
Occur among the test programs. Initially a gross value was 
estimated for each category; subsequently this value was dis- 
tribúted across the programs of the category. 

The processor speed ratio ajj and the static 
storage ratio b.. were obtained by combining the above quantities 


+) 


eis +o lMbows: 
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jeer oOoLLeations Software Life Cycle Cost 
a. General 
Cost estimation for large-scale computer software 


huNbeen traditionally a risky undertaking. The reasons can 
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be found in the complexity of the systems programming effort, 
coupled with the rapid change in technology and applications. 
In accordance with F.P. Brooks, Jr. [33] rule of thumb estimation: 


efe 


The promotion of a simple debugged program to a 
generalized, tested, documented and maintenable programming 
product (so that anyone can use, fix and extend) costs three 
times as much as the debugged program itself. 

The promotion of the same program to a programming 
Hen which is a collection of interacting programs, coordi- 
Ated in function and disciplined in format, so that the assem- 
Pase constitutes an entire facility for large tasks, costs at 
least three times the program itself. 
The promotion of the same program to a programming 
system product, which differs from the simple program in all 
of the above ways costs nine times as the program itself. 


Figure VII-8 illustrates the evolution of the pro- 


gramming system product. 
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Figure VII-8: Evolution of the programming systems product. 
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Traditional cost estimating methods have used one 

amore of the following techniques: [35] 

Top Down Estimating 

moema eom oa tne cost of all; or large por- 
tions, of the project to be estimated relies on the corresponding 
costs of previous projects, that have been completed. The disadvantage 
EX ndtothere is 1) substantial risk of overlooking special or 
difficult technical problems that may be buried in the project 
tasks and 2) lack of details needed for cost justification. 

Similarities and Differences Estimating 

The jobs to be accomplished are broken to a 
level of detail, where the similarities to and differences from 
previous projects are most evident. Work units which cannot be 
compared are estimated by some Other methods. 

^ Ratio Estimating 

The estimation relies on the sensitivity coeffi- 
ements or exchange ratios, which are invariant, within limits, 
to the details of design. The software analyst estimates the 
Size of a module by its number of object instructions, classifies 
it by type and evaluates its relative complexity. An appropriate 
AOS matrix sS constructed from a cost data base in terms of 


eea e instruetion for that type of software, at that com- 


plexity level. Other ratios, empirically derived, can be used 
rota estimation process e.g., CPU time per instruction, 
peripheral usage to CPU usage etc. The method is simple, fast, 
convenient in the proposal environment and beyond. It suffers, 
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as all methods do, from the need for a valid data base for many 
estimating situations (business vs. scientific, real time vs. 
non-real time, operational vs. non-operational). 
Bottom-Up Estimating 
This is the technique used mainly when estimating 

fovernment research and development contracts. The total job 
is broken down into relatively small work packages and work 
units, until it is reasonably clear what steps and talents are 
involved in doing each task. Each task is then estimated and 
]ucEcosts are summed-up to form the total project cost. An 
EE acce rs that the job of estimating, can be distributed 
femene people, who will do the work. A difficulty is the lack 
of immediate perspective of the most important parameter of 
“mie the total cost of the project. In software engineering 
cost estimates the top-down estimation is used as a check on 
the bottom-up tecnnique. 

b. The TRW Software Cost Estimation Algorithm [34] 

TRW has developed a cost estimation algorithm, 
based on the assumption that costs vary with the number of 
Br erterions, For each identified routine, the procedure 
combines an estimate for the number of object instructions, 
Category, relative degree of difficulty and historic data in 
dollars per instruction from the cost data base to give a trial 
estimate of the total cost. 
The first step in the method is to categorize the 


software routines, which were considered in the preliminary 


lis 








design phase. Categories which have stood the test of 
usage in several proposal and preliminary design are: 

Monica E) which controls" execution 
flow and is non-time critical. 

Input/Output routine (I), which transfers data 
Au Eon out ot the computer. 

Pre or post-algorithm processor (P), which mani- 
pulates date for subseguent processing or output. 

Algorithm (A), which performs logical or mathe- 
matical operations. 

Data management routine (D), which manages 
data transfer within the computer. 

Mamere i i ea processori which is- highly 
optimized machine dependent. 

The next step is size and complexity estimates by 
routine, or subprogram by the designer. To balance cost and 
risk, the designer may decide to use software elements, which 
are available to him from a software algorithm and needs only 
some degree of modification or adaptation. To account for the 
degree of difficulty of a given kind of routine, the designer 
Pr emetes a risk or complexity factor. This is the most crucial 
step in the estimating process, for it establishes the cost 
of the routine with all direct and indirect charges amortized 
against it. The other steps determine how the total cost wil 
be spread over the development cycle. The simplest technique 


for narrowing down the many subjective choices early in the 
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Sima tion process is to ask, if the routine is new or old on 
Euechand end if it is easy, medium or hard on the other. 
Biererore six levels of difficulty for each routine are 
realized as follows: 
Easy Medium Hard 
Oad OE OM OH 
New: NE NM NH 

The only parameter that changes, as a function of 
Hesbes of difficulty (OE through NH) is cost per instruction. 

The third step is to identify the various software 
development phases from the conceptual stage to delivery of 
the operational software to the user. For each phase an esti- 
mate is required for the fraction of the total amount to be 
aM cated to it. 

The fourth step is to define the activities in each 
development phase by means of an activity array and associated 
cost matrix. The activities as a function of development phase 
is a Number of activities times the number of phases matrix. 

Ew pyceal activity array is illustrated in Figure VII-9, where- 
by the corresponding cost matrix is shown in Figure VII-10. 

Men a step Sebring Upestne initial conditions 
for the cost estimation algorithm, is to provide schedule data 
based on the customer's statements of work, or other manage- 
ment considerations. Schedule data is input as months from 
go-ahead for each of the milestone periods. Burden rates are 


input for projected overhead rates, general and administrative 
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and so forth. Labor mix is defined and unburdened bid rates 
mee the labor grades, desired for the phase, is defined. Other 
direct changes are input, which for software is typically 
Beeveleas 4 percentage of direct labor costs, such as 3 per 
cent and documentation at 10 per cent. 

Computer usage data for a CDC 6500 class with time 
shared central processor unit based on sampled data from a pro- 


gramming department by month has been: 


Ne. of oi allNo. or No. of processor Peripheral 

MIS processor units hours per MM hours per MM 
used 

BIO OO 22, Tas 

B5 Sd s D 4.4 

Bo 30.0 Te 4.5 

33 46.5 202 ed) 


I chnessesnputer$um409 0942553 figure of 3 hours 
per man per programmer man-month would be reasonable. At an 
wae productivity of 1 object instruction per hour, this is 
equivalent to 156 instructions per man-month, or 1.2 minutes 
per instruction. The data in the third column are based on 
imi eeprocesson Units, corresponding to one hour of computing 
time. A computer hours matrix in terms of usage rate per 
instruction by phase is shown in Figure VII-11. 

The summary output from the cost estimation algo- 
acen includes: 

cost per routine, based on historic or proposed 


burden rates. 
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Figure VII-9: Activities as a function of Software Development 
Phase, 
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average cost per instruction, number of instuc- 
pons and category. 

simple graphic display of schedule and events. 

cost breakdown by development phase per routine 
in total dollars and per cent. 

cost breakdown by activity, by routine and summed 
up Over all routines in the software, such as management, review, 
entation, Specification, design, Coding, and testing. 

manloading and cost summary by segment showing 
Maese monta the labor breakdown for senior staff, staff, 
poca Clerical; also computer hours by month, other direct 
charges, cost by month and cumulative costs. 

The outputs from the cost estimation algorithm are 
considered a "trial set" for the cost estimation group. The 
trial set is used in combination with all other sources of data 
Besser cost position against objectives. The approved trial 
set, which contains the best judgemental and quatitative measures 
of cost per software element and per activity, becomes the input 
pone Motiicial pricing computer run. The official cost figures 
are produced by cost guidelines, approved rates and procedures, 
which have been established by the in-house pricing group and 
approved by the Government auditor. 

This cost estimation approach has the following 
advantages: 

the amount of data required to obtain a cost 


er Simate is minimal. 
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Figure VII-10: Cost matrix data showing allocation of resources 


as a function of activity by phase (category P). 


PHASE CATEGORY 
C i P A D T 
A 0 0 Q 0 0 0 
B 0 0 0 0 3 9 
C 0 0 0.0017 0.0007 0.0007 0.01 
D 00017 0.0017 0.0017 0.0017 0.0017 0.01 
E 0.007 0.005 0.006 0.007 0.007 0.04 
P 0.008 0.006 0.01 0.007 0.007 0.04 
G 0.005 0.004 0.005 0.004 0.004 0.005 
H 0 0 0 0 Q 0 
EXAMPLE: THE COLUMN SUM OF CATEGORY C, 


CONTROL ROUTINE, IS 217 x 10-4 HRS/ 
INSTRUCTION, OR 1.4 MIN/INSTR. THE 
TOTAL RESOURCE REQUIRED IS THEN 
OISTRIBUTED OVER PHASES D THRUG 
AS SHOWN ABOVE, «.4., 0.42 MIN/INSTR 
FOR PHASE E, CODING AND AUDITING. 


Computer hours matrix, showing computer usage 
aliaestion es 2 function or phase, 


Figure VII-11: 








AS 


the software designer immediately sees the cost 
consequences of his design. 

= Cem hee e ee routine is directly trace- 
able to a requirement, the requirement is directly traceable 
Bez total cost. 

comparisons or alternate schedules or resource 

allocations can be made rapidly. 
cost justification is produced, which can stand 


Mer test or a Government audit. 


ces Malitary Computer Family (MCF) Application 
Berem ycle Cost 


Ihe applications software life-cycle cost for sys- 
Rena Using architecture jJ is defined as: [29,30] 
EE - Cs: Si Le (VII-13) 
where: 
cos Ein dollars) per instruction of applica- 
tions software for architecture j 
A epi rcations SOltware size (in instructions), 
derived for the proposed system's data (see 
Table VII-I) 
L apo l1cations sottwarme lire cycle cost factor, 
i.e., ratio of applications life-cycle cost 
CN 5g sltlom COSt 5-5 presently). 


Figure VII-5 showed a strong correlation between 


total dollars investment and the cost-per-instruction for software. 
This correlation is even stronger, when cost per instruction is 


uud to the Tool Availability Index (TAI): [29,30] 
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P and D are fractions applied to the proponent's stated memory 
requirements which reflect an estimate of memory used for programs 
(P) vs. data (D). Values are expressed in megabits. 


A S; stated in 10° instructions. 
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where: TAI 


Ratio of available software tools to the ideal 
Sermon SOltwaré tools. The “ideal set" has been 
defined for the MCF Project. By knowing the TAI 
Fon ventarenatecture for any point in time; 
OncaucdnEciccdmnessomne mouse cu [30] an esti- 
mated cost per instruction. 
r = @orrelation coefficient 
However TAI is not as easily evaluated as investment 
inventory and the relationship of Figure VII-5 is more usefully 
applied. 
MCF provides an evaluation of the costs of each 
element of the TAI elements, which are presented in Table VII-2. 
Gee cose Model Proposed by EL. A: Putnam [35] 
Putnam has examined the problem of an early sizing, 
cost and schedule estimates for an application software system 


and has proposed the following software equation: 


SR oue s (VII-15) 
where: 

22. 5 size of project in source statements 

C Estate of technology constant 

K = life cycle effort in man-years = D B 


where D is the magnitude of the difficulty 


gradient, empirically found to be related to 
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Figure VII-12: Availability Index (%) 


REMARKS: 
1. The curves show the variation of cost per instruction as 


UNE bien Of the Tool Availability Index (TAI) for three 


conditions: (a) worst case, (b) best case and (c) derived 
median. 
2. As the percentage of available software tools increases, 


the cost per instruction of application software can be 


Seen to diminish. 
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Table VII-II: sortware Tool Costs 
Software Tool 


Noninteractive Debugging Aids (CMS-2) 


Language-Independent Monitor 
Compiler + Cross-Compiler (CMS-2) 


Real-Time + Time-Sharing Operational System 
Computers + Cross-Compilers (TACPOL) 

Test Case Instrumenter + Analyzers (TACPOL) 
Noniteractive Debugging Aids (TACPOL) 
Language-Dependent Monitor (Assembler) 


Test Case Instrumenter + Analyzers (CMS-2) 


Assembler 

Macro Assembler 

Basic Linker 

Simple Overlay Linker 
Interactive Debugging Aid (Assembler) 
Test Data Auditor 

Beer Data Generator 
integrated Library 

Data Base Management System 
Text Processing System 
Matevactive Source Editor 


General Purpose System Simulator 


ns acatar? Simulator 
Ferecmerters (Fortran) 


Test case Instrumenters + Analyzers (Fortran) 


Compilers + Cross-Compilers (Fortran) 
Noninteractive Debugging Aids (Fortran) 


Extended Overlay Linker 


E/G 


Cost 
(1977) 
SIC 
OS 


3300K 
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280K 
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system development characteristics measuring 
enome reer R Onc Urr rency Of Minor task 
accomplishments. 

t¿ = development time in years 

Equation VII-15 is derived from the Norden/Raleigh 


distribution equation: 





E 
K 2t ^ 
y = te d in MY (VII-16) 
ta 
where: y = manpower at any time t 
K s area under the curve and is the nominal life 


cycle effort in man-years 

E. che time of peak manpower in years and corre- 
sponds very closely to the development time 
for the system. 


The state-of-technology constant C, Can be 


k 
determined by calibration against the software equation, using 
data from projects developed by the same software house, Using 
similar technology and methods. 

Figure VII-13 illustrates a parametric form of 
equation VII-15. 

Mo e ce ans 

Given the broad preliminary size of the project, 
PERT technique is applied to get an overall system size range 
and distribution as follows: 

* An estimate of the expected value of a beta 


Sherer ait LlOn 15: 
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where: 


cemaller pOssible project size estimation 
Loco e cis ze estimation 
largest possible project size estimation 


The overall expected value is the sum of all 


the individual expected values (major functions) 
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ie eiven by: 


er 
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and the overall 


* An estimate of the standard deviation 
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standard deviation estimation by: 


i=l 


(2) Development time-effort determination 
Equation VII-15 is solved for K 
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in man-years (MY) 


In terms of development effort E = 0.4 K, so 
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DE = 0.4 — in MY 


Ener gevelspment Effort Cost (DEC) is given by: 


3 $ 
SLOC = MY K 


K S 
SEG - M Y 0.4K 


(3) Manpower and Cash Flow Pattern 

With the parameters for Development Effort 
(DE) and Development Time (ty) known, the generation of the 
manloading and the cash flow pattern for the software develop- 
ment period can be estimated, by using the Raleigh/Norden 
equation which gives the instantaneous manpower, that 1s equa- 
item Vii-16. 

The cash flow is just the average dollar 

eost/ MY times y: 


Cash Flow = y RM A 
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IE RNA ASESOR. THE HELLENIC. NAVY 


The alternatives for computer systems acquisition for the 
Hellenic Navy (HN) can be describes as follows: 
Acquire already developed systems from U.S. Navy or 
oner NATO navies or countries. 
- Description: 

Mikes setts! plone SamMedic =ro include: 

1) Hardware and software packages of existing systems. 

ii) Tailoring of the systems to the specific needs 
@retme HN by the vendor in consultance with the HN. 

iii) Attainment of support capability by the HN. 

It is understood that ener will eontinue to 
provide certain agreed field changes in hardware and software. 
- strengths: 

This alternative will give the HN the capability to 
operate and support selected systems, exploiting the experience 
am he developer navies or countries. 

- Weaknesses: 

This alternative has the following weaknesses: 

i) It represents the most expensive approach, since 
all technology involved has to be transferred from the vendor 
each time. 

eS to lets me factive participation ol the EN 
only to certain portions of the system application (statement 


of the functional needs, support). 


Al 








Acquire certain hardware and software packages and 
HEN SIS». others to complete a system. 


- Deseriztion: 

Bes appreeach 1s meant to include acquisition OF 
certain already developed packages of hardware (e.g., displays) 
and software (e.g., ballistic algorithms) and develop others 
required to complete a desired system. 

- otrengths: 

This alternative will give the HN the capability to 
Operate and support desired systems by integrating existing 
technology complemented by developed technology. 

It is a challenging approach, which may enhance the 
technological capability of the HN and reduce costs significantly. 

- Weaknesses: 

It seems that there are no serious weaknesses for 
the application of this approach. The risks involved are rather 
of lesser significance, especially when undertaking small scope 
development projects. 

^ Generate own capability to develop systems. 
- Deserıption: 

This alternative is meant to inclüde generation of 
a capability to develop desired systems from conception to 
Operational and support. All software required is to be developed 
by the HN. Hardware acquisition is to be effected through com- 


petitive procedures. 
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- sereng Chs: 
This approach is very dynamic and will provide the 
EN with the capability to operate and support systems through 
system development efforts carried out solely by the HN. The 
benefits of this approach cannot be overemphasized. The HN 
will be in a position to create its own desired systems. 
- Weaknesses: 
This alternative is desirable as a long range objec- 


tive, but may not be feasible in the near future. 


1823 





IX. SUMMARY AND CONCLUSIONS 


Bramsche examination Of Sections III to V, it is concluded 
Hou splous effort is continuously spent by countries of 
che North Atlantic Alliance towards the evolution of the Command 
and Control systems they have developed, and the improvement 
of the Communications, Command and Control Management. The 
Baar amee itself will benefit from the individual nations advances, 
but the real improvement will come when the cooperation between 


Europe and North America in the c? 


area, is eventually facilitated 
through the so-called "two-way street" concept. 

The examination of Section VI provides a good measure of 
the complexities involved in the development of a major computer 
System application. Systems analysis is the answer to these 
complexities and should be always applied when such a develop- 
ment is about to be undertaken. 

Feonsche cost eonsiderations of Section VII, it is concluded 
that the advancing technology allows the production of very 
effective and reliable hardware at low cost. This will con- 
tinue to be the case in the future. On the other hand, develop- 
ment of software is presently a rather expensive undertaking. 
Maintenance of the developed software is even more expensive. 
Software will continue to be expensive until software engineering, 
maturing with time, solves the existing software problems and 


dman ehes iL elf On a better Scientific foundation. 
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The examination of Section VII shows also that there are 
methods to quantify software sizing, cost and development effort 
and this can provide the answers required by the management. 

Section VIII provides a possible range of alternative 
approaches for the Hellenic Navy towards the acquisition of 
computer systems to fulfill her needs. All of the approaches 
foresee an active involvement of the HN in the acquisition/ 
development process. This involvement increases as we proceed 


NEUE SDpPoach-.one to approach three. 
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X. GLOSSARY OF TERMINOLOGY 


ALGORITHM - A prescribed set of well-defined rules or processes 
Ponsche solution of a problem ima finite number of steps. In 
principle, the steps are sufficiently basic and definite, so 
that a human can conceptually carry out the prescribed steps 


exactly even though the time to do so is impractically long. [36] 


APPLICATION PROGRAM - A computer program which directly contri- 
butes to the processing of end work, as opposed to computer 


systems program, language processors and other utility programs. 


ERCHTTECTURE OF A COMPUTER - The design personality of a computer. 
It can be viewed from two aspects: 1) hardware aspect and 2) 
software aspect. 

The hardware engineer may view the computer from the hard- 
ware aspect, that is by the technology involved; LSI, CMOS, 
Pepoiae, Core, pipelining, DMA, data bus, word size, etc., are 
all terms that may describe one processor as opposed to another. 

The software engineer may describe computer architecture 
by the attributes of a system, as seen by the programmer, i.e., 
the conceptual structure and functional behavior, as distinct 
from the organization of the data flow and controls, the logical 


design and the physical implementation. 


ADIDAS A Formal or official examination that attests to the 
conformity (or non-conformity) between two supposed equivalent 


entities according to a predefined set of rules. [36] 
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Pee TE DATA PROCESSING SYSTEM (ADPS) - A type of computer 


system used to support administrative or management systems. [18] 


BATCH PROCESSING - A mode of computer processing, which is char- 
acterized by the concurrent availability to the computer of a 
complete set of input data for a given job to be processed, 

the execution of which is not controlled in real-time (i.e., 


Men=line) by a user. 


BENCHMARK - A set of computer programs and associated data 
tailored to represent a particular workload, which is represent- 
ative of the user's application and used to test the capability 
of a computer system to perform that workload within a pre- 
determined limit. Benchmarks are used for evaluating vendor 


EOmpULter Systems. 


BOTTOM-UP PRINCIPLE - A synthesis from concrete, low-level details 
by stepwise integration into higher-level capabilities or more 


abstract concepts as a method for solving a problem. [36] 


CHECKOUTT- Informal validation of a program or a part of program 
by members of the development team, once the item has been 
successfully compiled (or assembled), by running a series oí 
test. When such validation is performed only visually, the 


Bee je referred as "desk checking". [36] 


CODING - The activity of expressing the steps of a given algo- 


rithm in a computer language (or, perhaps more than one language). 


A unit is not qualified as "coded" until compiled (or assembled) 


and all syntax errors removed. [36] 
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DATA - Representations of measurements, observations, facts, 
statistics, or derived quantities, either actual believed or 
assumed, in a form suitable for communication, reorganization, 
storage, retrieval, processing and dissemination. Contrast with 


INFORMATION. [36] 


DATA BASE - A collection of mutually related data items, usually 
stored together, to serve one or more applications by end users. 
As a goal, the data base has little (or not at all) controlled 
redundancy, is stored so as to be independent of the usages 

made of its contents, yet is stored for optimal efficiency by 
such applications and is capable of being subjected to a common 
and controlled approach, when adding new data or modifying or 
retrieving data existing within the data base. A "data base 
system" is a collection of separately structured data bases 


united by regulated interaction to form an organized whole. [36] 


DATA BASE DESIGN AIDS - Tools assisting data base designers 
in grouping data elements into logical record classes and in 
determining the relationships among logical record classes 


ae] esther the nature or the usage of the data. 


DATA BASE MANAGEMENT SYSTEM - Allows the use of a computer 
system to define the contents of and the logical relationships 
between collection of data items that represent some useful 
abstraction of a real-world phenomenon (tactical command and 


control system, the modules and documentation of a system of 
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computer programs) without being concerned with the physical 
mechanics of storing, locating and retrieving items or groups 


@r items. 


DATA DICTIONARY SYSTEMS - Tools assisting data base designers 


in managing the data definition activities. 


DATA MANIPULATIÓN UTILITIES - Allow the system user to alter 
the form and content of data files independent of the logical 
significance of the data fields involved. Specific tools are 
Sort/Merge programs and Editors (Interactive Source Language 
Bons. Interactive Object Module Editors, Batch Source 

Language Editors and Batch Object Module Editors). See also 


BEEELITIES. 


DEBUGGING - Detection, location and repair of inconsistencies 
between the program response and its functional or programming 
specification. A program or procedure ls said to be debugged 


if no known anomalies are present. [36] 


DEBUGGING AIDS - Assist the programmer in locating the sources 

of program errors that have been discovered during subsystem 
testing, usually by giving him some control over the execution 

of the module under test, that is external to the normal pro- 

gram code. Specific tools are Interactive Symbolic Debuggers, 
Non-Interactive Symbolic Debuggers, Interactive Absolute Debuggers 


and Non-Interactive Absolute Debuggers. 
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DOCUMENTATION AIDS - Assist in the preparation and maintenance 
of documentation about the modules of a system. Specific tools 
are Text Processing System, Flowchart Construction Languages 


amd Automatic Flowcharters. 


EMBEDDED COMPUTER SYSTEM - A computer system, that is "physically 
incorporated in a larger system, whose primary function is not 
computation. An electromechanical devices, a combat weapon 
system, a tactical system, an aircraft, a ship, a missile, a 
spacecraft, a command and control system, or a communication 
system are examples of larger systems. 

Embedded computer systems also include the support software 
for their own design, development and maintenance. Computers 
used primarily for data processing, scientific, or research 
application are not normally included among embedded computer 


Syesvems. 


FIRMWARE - It is programmed software. It is software merged 
into hardware because it combines programming with nonalterable 
hardware. For example a microprogram (a program residing in 


ROM), because it is unalterable is called firmwave. 


HARDWARE - Consists of the physical devices of a digital com- 
puter system, by means of the action on their circuitry on 
coded representations of which, the processing on information 


is accomplished. 
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These devices 


CORE 


ROLES > LING 
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are.: [172] 


Control eoe eS ne Unat (CPUS on mainframe) 


f, 


vs 
» 


The engine that drives the whole system. 
Mairie arae teristic: (Fest 

Processes information. All operations 

fall in three simple classes: 

- move information around 

- do arithmetic 

- perform logical operations 

Controls to pena ns Ounltsels, sand sail 
attached equipment, obeying human's computer 
programs 

Human operator runs it from "control panel" 


Gm icon+« rol console | 


Core Memory 

Core Memory is the internal information 
SeOrenouse Of tne computer. 

d nouns nes memory as opposed to 
ID MP cc PE 

Core memory is fast and expensive, but is 
getting cheaper. 

Basic storage unit, called a "byte" (eight 
bits) stores two hexadecimal digits (0,1, 
.93,A,B,..,E) letters (A-Z) and other 


Symbols E etes 
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Storage in core memory is located by "addressees". 


CPU Channels 
T i ii * Paths for information going eo fron CPU. 
CHANNELS 
y y $ * Devices attached to CPU to communicate 


electronically with it via these channels. 


MENS TA collection of related information units (records), 
which contain data in a particular state: sorted on a particular 
key, for example item name. Files are normally kept on secondary 


computer-storage devices. 


INFORMATION - A representation of knowledge, intelligence, or 
other meaningful data in a form that can be used to cause or 
modify the purposeful action of humans or machines, perhaps 

as a result of proper organization, analysis and presentation. 


Bonerast with DATA. [36] 


INFORMATION RETRIEVAL SYSTEMS - General purpose application 

programs operating either on-line (interactively) or in batch, 
that interpret user requests to locate and display information 
that isstored either within a structured data base, or within 
separate files. Specific Tools are Query Language Systems and 


Report Writers. 


INFORMATION STRUCTURE - A representation of the elements of a 
problem or of an applicable solution method for a problem, 


imss cantas its information base is concerned. 
INFORMATION SYSTEM - An assemblage of methods, techniques, pro- 
cedures, programs, or devices that sense, convey, store, 
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PROCESS. retrieve, or disseminate information, united by regu- 


bated interaction, to accomplish an organized purposeful task. 


INSTRUCTIONS - The repertoire of a language or (virtual) 


mahine. 


INTERFACE - When applied to a module, that set of assumptions 
made concerning the module by the remaining program or system, 
in which it appears. Modules have control, data and services 


interfaces. [36] 


INTERFACE TESTING - Validation that a module or set of modules 
Operate within agreed interface specifications to assure proper 


data and logical communications. 


NNNEBSPERABILITY - It 1s the ability of systems, units or forces 
to provide services to and to accept services from other systems, 
units and forces and to use the services, so exchanged, to enable 
them to operate effectively together. It includes compatible 
command and control systems, procedures, weapons systems, air- 
borne and ground-based navigational aids, electronics, communi- 
cations, procedures and equipment for identifying friend from 


Mees vdmd Cross servicing facilities. 


meee Or ACCESS = A set of functions, macros, subroutines, etc., 
that access a particular data structure or type of data struc- 
ture, through which all accesses to that structure or type, 
EP ose wasthin the function, etc., must pass. Also called 


"alusters" or "Parnas modules". 
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LIBRARY (Benchmark Library) - A collection of synthetic programs, 
which have been tested and documented for general use by Govern- 


ment agencies in computer benchmarks. 


BEBRARY Cor partitioned data set) - A group of related files, 


logically belonging to separate projects or tasks. 


EURO - A body of text substituted directly for a statement or 
portion of a statement recognized to be of a proper form. Macro 
invocations may transmit parameters for substitution or for 
processing before substitution into the code body, that replaces 


pacornvocation. 


MODULE - Identifiable subportions or a program composed of in- 
StPuctions or statements in a form acceptable to a computer 
prepared to achieve a certain result. They are characterized 

by lexical binding, identifiable, proper boundaries, named 
access, and named reference. The word "module" may apply to a 
subprogram, subroutine, routine, program, macro, or a function. 
A "compiled module" is a module or set of modules that are dis- 
crete and identifiable with respect to compiling, combining with 


other units and loading. 


MONITOR - A level of access on a shared resource in a program 
with concurrent processes, including the means for arbitration 


of that resource. 


MULTIPROGRAMMING - A capability of a computer system to have 


more than one process (program) in a state of execution at 
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the same time (see states of execution). It was used as a 
technique to increase the throughput activity. Multiprogramming 


does not require multiprocessing. 


MULTIPROCESSING - A capability of a computer system to have 
Mere than one processors, to handle the work load. 

Several multiprocessing systems have been developed, such 
as: 
Early systems, where the additional processors had 
Emeetalized functions, e.g., 1/0 channels. 

; Later systems, having one large CPU and several peri- 
perc processors, performing quite sophisticated tasks, such 
An ing a display. 

5 More common systems, having two or more processors, 
each of equal power. 


The computer networks, in which many different computers 


are connected often at great distances from one another. 


BIN TINGOSYSTEM - A collection of programs within a computer 
system, which controls the use of available resources (processors, 
memory, backing store, I/O devices, files), in order to facili- 
tate the computer system. 
The following types of operating systems, with their capa- 

bilities are in use today: 

Basic Operating System (BOS) 

Runs single user processes from initiation to termination. 


May or may not overlap I/O with execution. Provides basic 1/0 
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apport, that allows user to refer to files symbolically and 
to read and write them without knowing the hardware details 
of the I/O interface. Provides basic batch supervisor services, 
Meat control normal and abnormal job termination, job-to-job 
transition, and operator communication. Provides a minimum 
base for program development by supporting at least one language 
translator and/or linker/loader. 

5 Multiprogramming Operating System (MOS) 
Eröyıdes all of che services of the BOS. Supports the 
concurrent execution of two or more user jobs by allowing the 
execution of any job to be suspended, while another is executed, 
without any special programming considerations in the user job. 
Prevents concurrently executing jobs from accidentally or inten- 
tionally destroying each other or the supervisor. 

" Multiprocessor Operating Systems (MPOS) 
Allows the computing load to be spread across more than 
one processor, based on automatic (programmed) load-leveling 
algorithms or operator control, but does not require special 
case programming in the user job. MPOS includes the shared 
Seemeg@e, loosely coupled and networked types. 

% reena l Machine Monitor (VMM) 
The operating system presents an interface to the user 
program, that makes it appear that the program is executing on 
a real computing system. 

E Time-Sharing Operating System (TSOS) 
This is a variant of the multiprogramming operating sys- 


tem, in which system resources are allocated to user jobs in 


PS 
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Such ad way, that all jobs appear to progress at the same rate. 
in addition, users are allowed to "interact" with, and receive 
output from their jobs via terminals. Such systems are opti- 
mized for response rather than throughput. 

* Real-Time Operating System (RTOS) 


Allows user jobs to be executed within specified short 


mame limits. 


OPERATION - A well-defined finite-time execution within a program 


performing a time-independent function, based on its input. 


PERFORMANCE MONITOR - Assists the programmer in quantifying 
the resource consumption characteristics of a program and in 
isolating performance-critical areas. Specific tools are 


Language Dependent Monitors and Language Independent Monitors. 


PESTPHERAL EQUIPMENT => Usually called simply "peripherals", 
these are external (to the CPU) devices, performing a wide 
variety of input, output and other tasks. "On-line" peripherals 
are connected electronically to the CPU. Others are "off-line" 
cte smcted. [42] 

These devices are: 

Printer 

* Produces pages of printouts. 
Called "output" device. 


Very slow compared to the CPU's electronic 


speed. 
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Pas eee tlhe ep 1 you ¿Disk 


ee 


Stores information by magnetic recording 

on continuously rotating platters. 

Handles huge amounts of storage "on-line". 
Storage is "random access", meaning the 
recording arms hop around fast to any 
Taddpess (leeation) on any “track ón any 
disk to "read" or "write" (record) information. 
Much slower than core, but much less expen- 


sive for a given amount of information. 


Tape Unit...Tape Drive...Tape 


efe 
e» 


Stores information on reels of magnetic 

tape. 

Permits plenty of storage "on-line", with 
huge additional amounts of reels in "library". 
Storage is "sequential", requires moving 
along length of tape to desired address. 


Slower than disks, less expensive too. 


Punched Card Equipment...Unit Record Devices 


Feeds punched card information into com- 
pocer eden card Ie a "unit record"). 
Punches cards from information fed out by 
SUR 

May include some sorting and collating 


(interleaving) ability. 
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CHANNELS 


Terminal - Typewriter Type 
Keyboard like typewriter or teletype, but 
with extra keys and controls for communica- 
tion to and from computer. 


May be "local" (near computer) or "remote" 





(connected to computer via cables, "data 
links", or telephone lines). 
Uoc perform both input” and "out- 
DUG ISDN ESSE SC 
Relatively slow. 

Terminal - Display Type 
Distinguishing feature is TV-like screen 
for displaying alphabetical, numerical or 


graphic information. 





Keyboard similar to teletypewriter plus 
Special keys and controls. 

Cap benio caio nreno te usually the latter. 
Relatively fast. 

Intelligent Terminal 

Has some data processing ability built-in. 
Communicates with CPU as necessary to 
obtain information and get big jobs done. 


Generally fast devices. 
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Local Peripherals Device Controller 
For multiple peripherals of one type (disks, 
bapesssete. na "controller" often stands 
between such a group and one Channel of the 


DEVICE CPU. 
CONTROLLER 


Ranas rorna tiron traffic between CPU 





t i t 1 MiGente Olle tysoteperipnerals., althouen 
EC AES sometimes a single peripheral (e.g., a 
Dante ci 1 tS own Controller: 
Communications Controller 
Handles information traffic to and from 
many remote terminals or computers. 
COMMUNICATION * Those controllers with special processing 
CONTROLLER : 


capa icon ron eaniz1ng anda checking 





T data are called "Front End Communications 
WEREPHONE LINES 
^ PLOCeESSON Gua 
EEMOTE TERMINALS 
S COMPUTERS 
Mene Storage Devices and Forms: 
Magnetic Drums 
Store information magnetically or continuously rotating cylinder 
providing faster access to information, than disks do. 
Floppy Disks 
These small flexible disks (about the size of a 45 rpm phonograph 
records) are used for: 


small random access requirements in controllers and CPUs. 


ScmoamecOonpactesSUbDSGituce for punched cards. 
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Mass Storage 


Massive amounts of storage, with slower access to it, providing 
lower cost for a given amount of information stored. 

Bicher Peripheral Eguipment 

Sempurcer Output Microfilm (COM) 

eeds Information onto microfilm. 

Key Data Entry Devices 

The equipment used to prepare data so that the computer can 
accept it, including the old keypunches (card punches) plus the 
newer key-to-tape and key-to-disk units. 

Print or Mark Readers 

These data entry devices "read" digits, letters, marks, lines 
of text, even whole pages,for input to the computer. There are 
EHE c OCR (Optical Character Recognition) devices and MICR 
(Magnetic Ink Character Recognition) devices. 

Paper Tape Devices 

NeScpunened paper tape, or puneh it, for input and output from 
eomputer . 

peor ters 

Convert computer output into drawings on paper or display-type 
terminals. They can produce line graphs, bar charts, maps, 


engineering drawings, etc. 


PROGRAM - A sequence of instructions. (Programs are sometimes 
loosely called "code"). Programs are placed into memory and inter- 
preted (executed) by a processor. While not in use, programs are 
often stored in some secondary storage device, such as disk, drum, 


Scape. 
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PROGRAM MAINTENANCE - It is that process through which: 

Discrepancies are isolated and corrected (discrepancies 
are malfunctions within the program, or its user documentation, 
resulting in the failure of the program to operate as specified). 

E Deficiencies are removed (deficiencies are significant 

program limitation. There are two sources for program deficiencies: 
1) a change in other software which the given program interfaces, 
2) the recognition by applications programmer groups of the need 
for program capabilities not yet developed). The process through 
which a deficiency is removed, constitutes a program "design 
change". 

Minor program improvements and extensions are implemented. 


Documentation is updated to reflect program changes. 


Consultation is provided to the users. 


PERT/CPM SYSTEMS - Based on Program Evaluation Review Technique 
(PERT) and Critical Path Method (CPM), these tools assist 


managers in planning and controlling project activities. 


PROJECT ESTIMATION SYSTEMS - Assist in the development of work 
breakdown structures and related performance standards for use 


in estimating project resource requirements. 


PROTOCOL = A rule preseribing the interface discipline and cor- 


rect procedures for communications with a program subroutine. 
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REFORMATTER - Working with a preprocessor during the intro- 
duction of structured programming construct into source program, 
that do not have them, assists the programmer in producing 
ei eEcuature programs by automatically controlling identation, 


Bir En lacements of comments, etc., to produce readable listings. 


ROUTINE - A program or program module, that may have some general 
or frequent use. If a program module, then a routine always 
Bemis tO the point of invocation after execution (i.e., a 


proper routine) or terminates abnormally. 


SCOPE - The range within which an identified unit displays itself. 
Scope of activity refers to the boundaries within which a data 
structure or program element remains an integral unit. Scope 

of control refer to the submodules in a program that potentially 
DIE csutc. if control is given to a cited module. Scope of 
error denotes the set of submodules, that are potentially affected 


the detection oí a fault in a cited module. 


SIMULATOR - Software simulator ls a set of programs, which, run- 
ning on another host computer, simulate a computer, whose machine 
language is the desired high level language. Simulators are used 
as tools for direct support to the software development activities 
and can be of the following types: 

5 General Purpose Simulators - Allow a user to construct 
a computer model of a real or proposed system and to perform 


simulation experiments to determine the behavior of the model 


under various operational computer. 
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Computer System Simulators - Similar in nature to the 
general purpose simulator except that their basic building 
blocks represent real computer components, whose modeled 
behavior approximates the throughputs, capacities and access 


times achievable on the modeled equipments. 


SOFTWARE - It is the collection of programs and data that are 
used to make the hardware of a computer system run. It does 
encompass the following subsystems: 

i: Executive/Monitor or Operating System 
It is the general manager of the computer system re- 
sources (memory, processors, peripheral devices, information). 
As a system takes up a considerable amount of core and disk 
storage. It performs general hardware control, input/output 
services, operator interfaces, job and task scheduling and a 
general framework in which all other programs operate. 

£ Program Production System 

Provides environment and tools for program generation 

capabilities (compilers, assemblers, interpreters), program 
development (service functions, debug aids), program test capa- 
bilities and general communications with the hardware and/or 
Operating System. 

5 Data (File) Management System 
Provides for formatted file manipulation-generation- 


update, retrieval, edit and report production-textual processing, 


man/machine interaction and overall data management. 
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Utility Program System 
Provides for "routine" or recurrent functions, such as 
sort/Merges, Sort Generators, File Data Converters, Data 


Preprocessors and System Editors and Generators. 


STANDARDS ENFORCER - Allows source programs to be examined auto- 
uNUcally and'"eheeked for conformance to installation- defined 


standards of format, content and usage. 


SUBSYSTEM - A portion of component of a system that can be 
designed and implemented independently of other parts of the 
Byetems) This does not exclude relationships between subsystems. 
Subsystems may be of two general types 1) the application sub- 
Siiseem (e.g-, material inventory) 2) support subsystems (e.g., 


data management, communications etc.). 


SYSTEM - An integrated assemblage of components (hardware, 

methods, procedures, programs), designed to achieve an objective. 

The following are emphasized, when considering a computer system: 

the role of the component in the system rather as an 
iiciweadual entity. 

the synergistic effect (whole bigger than the sum of 

parts). 

” Memo o uc alracet (COntememand structure of information). 

“ the physical facet (hardware and software). 


^ the fact that system maintenance is required for the 


reto the system. 
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SYSTEM DESCRIPTION LANGUAGES 6 ANALYZERS - Tools assisting 
systems analysts in describing the functional characteristics 
of a system and in validating the consistency and completeness 


of a functional decomposition. 


TEST CASE DESIGN ADVISORS - Analyze programs written in a high 
level language and present the results of that analysis in a 


form suitable to assist test case designers. 


TEST DATA AUDITORS - Compare data files against specification 


and produce reports of discrepancies and/or compliance. 


TEST DATA GENERATORS - Create data files for testing and 


validating programs. 


TEST INSTRUMENTS AND ANALYZERS - Instrument modules under test 


SO as to collect data characterizing the behavior of the model. 


TRANSLATOR - A program that takes as input a program written 
in one programming language (the source language) and produces 
as output a program in another language (the object or target 
language). 

The following translator are used in computer systems: 

5 COMPILER - Translates programs written in a High Level 
Language (HLL), such as PL/1, FORTRAN or COBOL into either 
relocatable object code acceptable to a Linker or to a Low Level 


Language (LLL), such as assembly, acceptable to an Assembler. 


INTERPRETER - 1t accomplishes direct execution of a 


simplified language, called Intermediate Code (IC), to which 
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certain other translators transform a programming language 
(e.g., SNOO BOL is often interpreted, the IC being a language 
called POLISH POSTFIX NOTATION). In some cases, the source 
language itself can be the IC (e.g., most command language 
Ene deb Control Language, in which one communicates directly 
with the Operating System, are interpreted with no translation 
Stall). 

ASSEMBLER - Translates the Symbolic Assembly Language 
(SAL) to machine language, which the computer can understand, 
as the statements of SAL generally correspond to a single 
machine instruction. Specific assemblers include Basic 
Assemblers and Macro Assemblers. 

EROLIOERSSORZ ZTranslates a HALL suéhfas a "structured" 
version of FORTRAN) into another HLL (such as the conventional 
FORTRAN) and vice versa. 

CROSS-TRANSLATOR - A program running on one machine, 
that produces object code for another machine. The cross trans- 
Prrersrums on a parent computer and generates code to be executed 
on a child computer. The parent computer typically executes an 
assembler or HLL compiler written in a common language like 
FORTRAN. The output from a parent computer is loadable object 
Sader ene Child computer. 

LOADER (or Linking Loader) - Translator, whose object 
code is actual machine code and whose source language is almost 


identical, usually consisting of machine language programs in 


207 





relocatable form together with tables of data specifying 
points, where the relocatable code must be modified to become 
pouly executable. 

It combines the text produced by separate invocations of 
Compilers of Assemblers ("object modules") into executable 
code strings ("load modules" or "core images"), that can be 
loaded into the main storage of the computer system and executed 
Exhout further preprocessing. 

Specific loaders are Basic Linkers, Simple Overlay Linkers 


and Extended Overlay Linkers. 


UTILITIES - Generalized software packages such as sorts, merges, 
data transcriptions, file maintenance, debugging aids, error 
handlers, checkpoints, accounting routines, dumps, labeling 
routines, copy routine, extracts, conversion routines, cata- 
Men Oout ines, programs maintenance routines, which are neces- 
sary to maintain the system and to process application date, 
huic cussenusijtive to data values E.G., the transfer of data 


from one storage device to another. 
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APPENDIX A 


CESC PRST STEMIDESCRIPTION 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Need S1ze 

No. of Registers 

fue. Execution Time 
Add/Sub/Load 
Multiply 
Divide 

Microprogrammable 

Technology 

Beuyılesed State 

Stack 


Main Memory 
Maximum Size 
Speed 
Word-size 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


lius: uetion Set 
DoüDle Precision 
Byte Manipulation 
Bre Manipulation 
o Point 
Hac pie Functions 
Negation 
Arithmetic Complement 
Steekslanıpulation 


Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 


UNIVAC 
MIL-E-16400 
PAE SD SIS UN 
ZU aer , 


2.000 watts 


30-bits 
ee (accumulators) 


8-12 usec 

8-12 usec 

Sel? usec 

No 

Discrete Components 
No 

No 


32K to 262K-words 
4 usec 

SDE 

No 

No 

Magnetic Core 

No 


es 

Yes 

No 

software Implemented 
software Implemented 
One's Complement 
One's Complement 

No 


32K-words 

No 

7 Index Registers 
No 





mo Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


Maintenance/Control Panel 
meecation 
Multi-register displays 


Patera l Program Load 


Reliability & Maintainability 
MEBSF 
MTTR 
Diagnostic Programs 


Menular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 


Interrupts 
Ensopitvy Structure 
Nesting Capability 
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16 
Parallel 
Unknown 
No 


Brom: Or Cabinet 
Yes 


Firmware 


1500 hours 
Unknown 
Yes 


No 


Yes 
CS-1 
Yes 
Yes 
Yes 
Yes 
No 
No 


Yes 
No 





APPENDIX B 


k= 7 Soro Eero Ck TPT LON 


Manufacturer 

Construction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 
Add/Sub/Load 
Multiply 
Divide 

Microprogrammable 

Technology 

Privileged State 

Tack 


Main Memory 
Maximum Size 
Speed 
Word-size 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


lu SepPuction Set 
Double Precision 
Byte Manipulation 
Em Manuvpulation 
HE uus Point 
Hm Functions 
Negation 
Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct 
imi rection 
Indexing 
Paging Hardware 


UNIVAC 
MIL-E-16400 
41"Hx24"Dx20"W 
DN A ESO OS > 


IO eS 000 watts 


32=-bits 
8 or 16 (accumulators) 


6.5 usec 

10.0 usec 

17.0 usec 

No 

Third Generation/MSI 
Yes 

No 


256K-words (16K/module) 
]a 59m sec 

3 bates 

NO 

Yes 

Magnetic Core 

9 ports/16K module 


Yes 

Yes 

Yes 

Hardware 
Software 

One's Complement 
One's Complement 
No 


262K-words 

Multi-level 

7 or 14 index registers 
No 





ime Controller 
No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 


MER tenance/Control Panel 
fScartion 
Multi-register displays 


Initial Program Load 


Reliability & Maintainability 
MTEF 
KETR 
Diagnostic Programs 


lar Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Basscor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 


Interrupts 
EAO y Structure 
Nesting Capability 


2a? 


16 
Serial/Parallel 
167,000 words/sec 
Yes 


Remote 
No 


Firmware 


Unknown 
Sm utes 
Firmware/Software 


Yes 


Yes 

POR Urey CMS —2 
Yes 

Yes 

Yes 

Yes 

SHARE/7 

Yes 


Yes 
NO 
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NASA RD ESCRIT PTION 


Manufacturer 

Bonscpruction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 
Add/Sub/Load 
Mitra) ly 
Divide 

Microprogrammable 

Technology 

Privileged State 

Spack 


Main Memory 
Maximum Size 
Speed 
Word-size 
Memory Parity Checking 
Memory Write Protect 
icons os 
Multiported 


ns trucción Set 
Boublespreeision 
Byte Manipulation 
Bit Manipulation 
Fleazıne Point 
Mata eee Functions 
Negation 
Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 


UNIVAC 

MIL-E-16400 
SUE D Doc TB 
o Se 


900 watts 


16-bits 
Boc General) 


UNS Se 

3.89 usec 

0.5 usec 

Yes (512 word growth) 
3rd generation/MSI 

No 

No ; 


65K-words 

0.75 usec effective 
I5=Bits 

No 

No 

Masnetic Core RAM 
Ij X CP poocesnd DMA) 


Yes 
Load/Index/Store/Compare 
Limited 

Yes 

Yes 

One's and Two's Complement 
Two's Complement 

No 


65K-words 

Multi-level 

All general registers 

64 page address registers 





APPENDIX D 


BASIC AN/UYK-20 HARDWARE CONFIGURATION AND OPTIONS 


Basic Con curatron 


n^ 


Microprogrammed Processor 

ap Output Controller 

16 General Registers 

Boet troo ROM = two programs for channels and peripheral 

devices selected by the user 

8K-words of Core Memory 

Power Supply as specified by the user: 

N Single phase, 115 volts, 60 or 500 hertz 

MEI Sccopbssemdelra Its volts. 60 or 400 hertz 

Beine enshase uye, 208 Volts. B075r 400 hertz 

Four Input/Output Channels (one group) as Specified by 

BR user: 

8 MIL-STD-188C Synchronous (0 to 9600 baud) 

ENMISLISTD-IS8C Asynchronous (four rates of 75, 150, 300, 
Cue 200, or 2400 baud) 

BER -242C Synchronous (0 to 9600 baud) 

B® RS-232C Asynchronous (four rates of 75, 150, 300, 
600, 1200, or 2400 baud) 

BeNTDS slow, fast, and ANEW in a normal or intercomputer 


mode 


Options Available 


8K-word Memory Modules (up to 65K-words) 
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APPENDIX E 


CUA CTERLSTICS OF HES 65060 © 6080 PROCESSOR MODELS 


HOD Ege SS MODEL 60 3:0 

EMS TEM CONFIGURATION 
luupen ot Central Processors l to 4 l to 4 
Number of I/O Multiplexers IN om 1 to 4 
Number of System Controllers aa. Ior 
MAIN STORAGE 
Minimum capacity (36 bit words) 98,304 polo 2 
Maximum capacity (36 bit words) 524,288 IS 
Increment Size (36 bit words) Varies Varies 
Cycle Time (microseconds) je O25 
Words fetched per cycle unit 2 2 
Storage Interleaving 2/4 Way 2/4 Way 
MENTRAB PROCESSOR 
Dr rended Business Instruction Set Standard Standard 
m erae c ion Overlap Standard Standard 
Pea peed (Instruction per sec) 
anesle Processor SOI TOO I 70002000 
Dual Processor 2,000 ee SOO 
Input/Output Control (Channels 

Pena O multiplexer) 8 to 24 posto 
Maximum Data Rate pe» I/O multi- 

plexer (characters per sec) 790.000 EQ 
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E O E: 


Vie pe — 1 l/s oo Mel DESC ROP TEON 


Menuracturer 

Pensemuction Standard 
Maximum Physical Dimensions 
Maximum Weight 

Maximum Power Consumption 


Architecture 

Word Size 

No. of Registers 

liusc Execution Time 
Add/Sub/Load 
Malal y 
Divide 

Microprogrammable 

Technology 

Privileged State 

stack 


Main Memory 
Maximum Size 
Speed 
Word-size 
Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 


Insteruetion,set 
Doubiskreeiısion 
Byte Manipulation 
Bit Manipulation 
Discs Point 
Math/Trig Functions 
Negation 
Arithmetic Complement 
Stack Manipulation 


Addressing 
Direct 
nales Lon 
imide <i ng 
Paging Hardware 


Dacttalweetiipmen: Corporation 
Commercial 

TES OD A WN 

SUC Sips. 


2,200 watts 


toot Cl bar addresses) 
16 (general) 


0.3 usec 

3.3 usec 

7.5 usec 

No 

Mio Col 

Two - Kernel & Supervisor 
Yes 


128K-words 

Im ao. 0238 usec 

16-bit (18-bit for parity) 
Yes 

Yes 

Core/MOS/Bipolar 

Single - UNIBUS structure 


Yes 

Yes 

Yes 

Yes 

Software 

One's or Two's Complement 
Beo R omp l ement 


Yes 

256K-bytes 

eis 

All general registers 
Yes 





io Controller 
No. of Channels 
Types of Channels 
Maximum Data Rage 
Processor Independent 


Maintenance/Control Panel 
Location 
Multi-register displays 


Initial Program Load 


Reliability € Maintainability 
MSIE 
METR 
Diagnostic Programs 


Modular Building Blocks 


Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 


Interrupts 
ato pare” Structure 
Nesting Capability 


Z3 


14 
Serial/Parallel 
1,000K-words/sec 
DMA only 


Front of chassis 
No 


Firmware 


Unknown 
Unknown 
Software 


Yes 


Yes 
FORTRAN/ALGOL/BASIC 
Yes 
Yes 
Yes 
Yes 
Yes 
Yes 


None 
None 





APPENDIX 6 


eran. COMPULER EAMUEY (MCF) BENCHMARK TESTS 


Message Buffer and Transmission 
Autocorrelation 

Ran able Seareh 

Linked List Insertion 

uapu t Driver 

Eres one 

Boolean Matrix Transpose 

Target Tracking 

Digital Communications Processes 
Character Search 

Record Unpacking 

Array Manipulation 

Meaaple Priority Interrupt 
Vector-to-Scan Line Conversion 
Scale Vector Display 


Virtual Memory Exchange 


Pies 
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